Custom roles let you bundle permissions into reusable packages that you assign to users or groups. You'll build a role that inherits from existing roles and controls access to specific tables and applications.
Why custom roles beat direct permission assignment
Before roles, you had to grant individual permissions directly to users — access to specific tables, modules, and applications one at a time. That approach creates a maintenance nightmare when someone changes teams or when you need to audit who has access to what. ServiceNow admins end up with users who have accumulated permissions over time, making it impossible to know what access is actually needed for their current job.
How role inheritance works
Roles in ServiceNow work through inheritance — when you assign a role to a user, they get that role's permissions plus all permissions from any roles it includes. Start with a base role that has the minimal permissions everyone in that group needs, then create specialized roles that inherit from the base and add specific permissions. The role itself is just a container — it only grants access when you reference it in ACL rules, assign it to navigation modules, or give it to users directly.
Production role management
Once your basic roles work, focus on role hierarchies that match your org structure and clear naming conventions that make the role's purpose obvious. Build roles that correspond to job functions, not individuals — 'incident_manager' instead of 'john_smith_permissions'. The best role structures use deep inheritance so changing base role permissions automatically flows down to specialized roles, and they're documented so other admins understand the permission model.
Before you start
- •user_admin role or admin role
- •Understanding of which tables and modules the role needs to access
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
Create the role record
Navigate to System Security > Roles and click New. Fill in the Name field with a descriptive identifier like 'incident_manager' or 'hr_specialist' — this is what you'll reference in ACLs and assign to users. The Description should explain the role's purpose clearly since other admins will see this when troubleshooting permissions.
Use lowercase with underscores for role names — it matches ServiceNow's naming convention and makes scripting easier.
Configure role inheritance
In the Contains Roles tab, add any existing roles this new role should inherit from using the insert icon. Common base roles include 'snc_internal' for platform access or 'itil' for ITSM functionality. Every permission from the included roles automatically becomes part of your new role — users who get your role will have all those permissions without additional assignment.
Check the Elevated Privilege box only if this role needs to bypass normal security constraints — most custom roles don't need this.
Set up table access permissions
Click to the Access Controls (ACLs) related list and create ACL rules for tables this role needs to access. For each table, specify the operation (read, write, create, delete) and set the Condition to reference your role using 'gs.hasRole('your_role_name')'. The ACL won't take effect until you save and activate it — inactive ACLs don't grant any permissions.
Start with read access only, then add write permissions after testing — it's easier to expand access than to troubleshoot why users can modify records they shouldn't.
Configure module visibility
Navigate to System UI > Modules and find the navigation items this role should see. Edit each module and add your role to the Roles field — users need both table permissions from ACLs and module access to actually use the functionality. Modules without proper role assignments won't appear in users' navigation even if they have underlying table access.
Application menus inherit role requirements from their child modules, so you usually only need to set roles on specific modules, not the parent application.
Test role permissions
Create a test user and assign your new role through System Security > Users > [user record] > Roles tab. Log in as that user in a private browser session to verify they can access the intended tables and see the correct navigation modules. Check both that they can access what they should and cannot access what they shouldn't.
Use the Security Debug plugin to see exactly which roles are granting access when troubleshooting permission issues.
Assign to production users
Add the role to users individually through their user records, or assign it to groups through System Security > Groups. Group assignment scales better — when someone joins or leaves a team, you just modify group membership rather than individual role assignments. Save the user or group record to activate the role assignment immediately.
Best practices
Create roles that match job functions, not individuals — when someone changes roles, you reassign the role rather than rebuilding permissions from scratch.
Use deep role inheritance so base role changes automatically flow to specialized roles — don't duplicate permissions across multiple roles when inheritance can handle it.
Test new roles with a dedicated test user before assigning to production users — role permission bugs are easier to catch before they affect real work.
Document role hierarchies and purposes in the role descriptions — six months later, you'll forget why a role was created and what permissions it's supposed to have.
Never assign the admin role as an included role in custom roles — it bypasses all security and makes it impossible to audit what permissions users actually need.
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