Client scripts can cause confusion when they fire for everyone — especially scripts that enforce field validations or hide sections meant for specific teams. This guide shows you how to restrict client scripts to users with specific roles or exclude certain users entirely.
The problem with unrestricted client scripts
Client scripts fire for every user who loads a form, regardless of their role or permissions. This creates problems when you need field validations that only apply to specific teams, or UI customizations meant for power users that confuse end users. Without role restrictions, you end up with scripts that block legitimate users or create unnecessary complexity for people who don't need it. Platform developers spend time troubleshooting why scripts misbehave for different user groups instead of focusing on functionality.
Two approaches to role-based restrictions
ServiceNow gives you two ways to restrict client scripts: the Roles field on the client script record for simple role inclusion, and programmatic checks using g_user.hasRole() for complex logic. The Roles field is cleaner for straightforward 'only these roles' restrictions — it prevents the script from loading entirely. The programmatic approach lets you build exclusions, multiple role combinations, or conditional behavior within the same script. Most developers start with the Roles field and move to programmatic checks when they need more flexibility.
Production considerations and security limits
Client-side role checks can be inspected and bypassed by users who know how to use browser developer tools — they're convenience restrictions, not security controls. Any validation or restriction that matters for data integrity must be enforced server-side with Business Rules or ACLs. The role restrictions you build here should focus on user experience improvements: hiding irrelevant fields, customizing workflows, or preventing confusion rather than protecting sensitive data.
Before you start
- •admin role or ability to modify client scripts
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 client script record
Navigate to System Definition > Client Scripts and open the client script you want to restrict. If you're creating a new one, set the basic fields (Name, Table, Type) first before adding role restrictions.
Copy the sys_id before you start — you'll need it if you want to test with different user accounts.
Set simple role inclusion
For basic 'only these roles can trigger this script' restrictions, scroll to the Roles field and add the roles that should see this script. Use the reference picker to select roles — don't type role names manually. This prevents the entire script from loading for users without these roles.
The Roles field uses OR logic — users need any one of the listed roles, not all of them.
Add programmatic role checks
For exclusions or complex role logic, leave the Roles field empty and add g_user.hasRole('role_name') checks at the top of your script function. Wrap your existing script logic inside an if statement that checks the role condition. This approach loads the script for everyone but only executes the logic for users who pass your check.
Handle multiple roles and exclusions
Use JavaScript logical operators to build complex conditions. For multiple required roles, use g_user.hasRole('role1') && g_user.hasRole('role2'). For exclusions, use !g_user.hasRole('role_name'). For either/or conditions, use g_user.hasRole('role1') || g_user.hasRole('role2'). Test each condition separately before combining them.
Test with different user accounts
Impersonate users with different roles to verify your restrictions work correctly. Check that users without the required roles don't see the script behavior, and that users with the roles get the expected functionality. Pay attention to users with admin roles — they often bypass restrictions you didn't expect.
Document the role requirements
Add comments to your script explaining which roles trigger which behavior, and update the Description field on the client script record. Include the business reason for the restriction — not just what roles are required, but why those specific roles need this functionality.
Best practices
Use the Roles field for simple inclusion logic rather than programmatic checks — it prevents unnecessary script loading and improves performance.
Never rely on client-side role checks for data security — users can disable JavaScript or modify client-side code to bypass these restrictions.
Test role restrictions with real user accounts, not just impersonation — some roles interact in unexpected ways that only show up with actual user sessions.
Document why roles are restricted in comments — six months later, you'll forget the business reason and wonder if the restriction is still needed.
Avoid checking for admin roles in client scripts — admins often need to work around restrictions for troubleshooting, and hardcoded admin checks create maintenance headaches.
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