Some business rules should only fire when certain types of users interact with records — maybe field updates by analysts need special handling, or you want to skip validation for managers. This guide shows you how to add role checks to your business rule conditions.
Why role-based business rules matter
Most business rules treat all users the same, but real workflows often depend on who's doing what. HR analysts updating employee records need different validation than managers doing quick approvals. Finance users creating purchase requests might bypass certain automated field population that regular requesters need. Without role-based logic, you end up writing multiple similar rules or building complex workarounds inside your scripts. Platform teams who maintain these systems spend too much time debugging rules that should never have fired in the first place.
How role conditions work
ServiceNow evaluates business rule conditions before running the script, so adding gs.hasRole('role_name') to your condition is the cleanest approach. You can check for specific roles (rule only runs for users with that role) or exclude roles (rule skips users with that role). The condition runs in the user's context, not as admin, so it sees their actual role assignments. Start with a simple role check on a single table, then expand to multiple roles or more complex logic once you understand the behavior.
Building robust role-based rules
Basic role checks work, but production implementations need to handle edge cases: users with multiple roles, inherited roles through groups, and roles that get added or removed over time. Consider whether you want to check for any role in a set (manager OR director) or multiple roles together (analyst AND regional_lead). Document your role logic clearly — six months later, nobody will remember why certain combinations were excluded. If your role-based rules get complex, extract the logic into reusable Script Includes that other business rules can share.
Before you start
- •admin role or business_rule_admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Open your business rule
Navigate to System Definition > Business Rules and open the rule you want to restrict. If you're creating a new rule, set up your basic configuration (table, timing, insert/update flags) first. You'll add the role condition before testing the rule logic.
Modify the condition script
In the Condition field, add gs.hasRole('role_name') where role_name matches the exact role you want to check. If you already have condition logic, combine them with &&. For example: current.state == 'open' && gs.hasRole('itil'). To exclude a role instead, use !gs.hasRole('role_name').
Test with a non-admin user
Save the business rule, then impersonate a user who has the target role. Perform the action that should trigger the rule (insert, update, etc.) and verify it fires. Admin users always return true for gs.hasRole() checks, so testing as admin will give you false confidence.
Create a test user account specifically for business rule testing rather than impersonating production users.
Test the exclusion case
Impersonate a user who doesn't have the role and repeat the trigger action. The rule should not execute. Check the system logs if you're unsure whether the rule fired — business rules that don't run won't appear in script logs.
Handle multiple roles if needed
For multiple role requirements, use gs.hasRole('role1') && gs.hasRole('role2') for users who need both roles, or gs.hasRole('role1') || gs.hasRole('role2') for users who need either role. Parentheses matter when combining role checks with other conditions.
Document the role logic
Add a comment in the business rule explaining which roles trigger it and why. Include the business justification, not just the technical implementation. Future maintainers need to understand the intent when roles change or new requirements emerge.
Best practices
Never test role-restricted business rules while logged in as admin — admins bypass all role checks and will give you false results.
Use exact role names from the sys_user_role table — gs.hasRole() is case-sensitive and won't work with display names or partial matches.
Place role checks first in compound conditions (gs.hasRole('analyst') && current.state == 'open') so ServiceNow can short-circuit evaluation when the user lacks the role.
Avoid checking for multiple specific roles when a parent role would work — gs.hasRole('itil') is better than checking for incident_manager, problem_manager, and change_manager separately.
Consider using role exclusions (!gs.hasRole('system_administrator')) for rules that should skip power users rather than checking for every possible regular user role.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue