Roles and Groups in ServiceNow Security

Introduction

ServiceNow's security model is built on two foundational concepts: Roles and Groups. Every ACL, every UI Action condition, every module visibility check ultimately asks: "Does this user have this role?" Understanding how roles and groups work together—and separately—is essential for any ServiceNow administrator.

---

Roles: What They Are

A Role is a named permission token. ACLs and other access controls check for roles, not group membership. Common built-in roles include:

Role	Purpose
admin	Full platform access; bypasses ACLs
itil	ITSM service desk agent
itil_admin	ITSM administrator
approver_user	Can approve/reject approval records
asset	Asset management module access
knowledge	Knowledge base read access
knowledge_admin	Knowledge base administration

Roles Are Checked, Not Groups

This is the critical distinction most beginners miss:

// ACL script: Checks role, not group membership
answer = gs.hasRole('change_manager');

// This is WRONG as a security check:
var inGroup = /* user in CAB group */;
answer = inGroup; // Groups don't grant roles unless configured to

ACLs check roles. Groups are a way of assigning roles to multiple users efficiently.

---

Groups: The Role Distribution Mechanism

A Group is a collection of users. Groups serve two purposes:

1. Role assignment: Assigning roles to a group grants those roles to all members
2. Work assignment: Incidents, changes, and tasks are assigned to groups for routing

Group Roles Tab

Navigate to a Group record and click the Roles tab. Any role added here is granted to all members of that group.

Group: ITSM Service Desk
  Members: John, Sarah, Ahmed, Priya
  Roles: itil, sn_incident_read, knowledge

All four members automatically receive itil, sn_incident_read, and knowledge roles.

Direct Role Assignment

Users can also receive roles directly on their User record (Roles tab). This bypasses group membership and is useful for:

• Temporary role grants
• Special permission for specific individuals
• Service accounts

---

Role Inheritance: Building a Hierarchy

Roles can include other roles, creating a hierarchy:

itil_admin
  └─ includes: itil
       └─ includes: sn_incident_read
                    sn_problem_read

If a user has itil_admin, they automatically also have itil and all roles itil includes.

Creating Role Inheritance

1. Open sys_user_role for your parent role
2. Click the Contains Roles related list
3. Add the roles that should be included

Designing Your Role Hierarchy

Custom Application Roles:

app_reader          → Read-only access
  └─ includes:
     sn_incident_read

app_user            → Standard user access  
  └─ includes:
     app_reader
     sn_incident_write

app_manager         → Manager access
  └─ includes:
     app_user  
     app_approve
     app_report

app_admin           → Full application admin
  └─ includes:
     app_manager
     app_configure

This hierarchy means granting app_admin automatically provides all lower-level permissions.

---

Elevated Roles and Security

The Admin Role

The admin role is special—it bypasses ACLs entirely by default. Use it sparingly:

Do NOT:
- Give admin to every developer "to make things easier"
- Use admin accounts for day-to-day work
- Service accounts running integrations should NOT have admin

DO:
- Create purpose-specific roles for integrations
- Use admin only for platform configuration
- Audit admin role holders quarterly

The maint Role

Similar to admin but intended for maintenance scripts. Avoid using in production configurations.

security_admin Property

Even admin users cannot modify ACLs without the security_admin elevated role, which must be self-activated via the Settings menu. This is a critical guardrail—enable it in all production instances.

---

Delegated Administration

Not all group/role management needs to go through your ServiceNow admin team. Use Delegated Administration to allow group managers to manage their own team's memberships:

1. On the Group record, set a Group Manager
2. The Group Manager can add/remove members from their group
3. They cannot add new roles to the group (only manage membership)

This scales your user management without giving broad admin access.

---

User Criteria (Service Portal & Catalog)

For the Service Portal and Service Catalog specifically, User Criteria controls visibility:

User Criteria: IT Staff Only
  Conditions:
    - Role: itil
    OR
    - Group: IT Department

Catalog items, pages, and knowledge bases use User Criteria rather than direct ACLs.

---

Auditing Role Assignments

Regularly audit who has elevated roles:

// Script to find all admin users (for background script or scheduled job)
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('role.name', 'admin');
gr.addQuery('user.active', true);
gr.query();
while (gr.next()) {
    gs.info('Admin user: ' + gr.user.user_name + 
            ' | Name: ' + gr.user.getDisplayValue() + 
            ' | Granted: ' + gr.getValue('sys_created_on'));
}

---

Best Practices

• Create custom roles for custom applications—don't piggyback on OOTB roles
• Build a documented role hierarchy before implementation
• Assign roles via Groups, not directly to users (for maintainability)
• Reserve direct user-level role assignment for exceptions
• Enable security_admin plugin in all instances
• Audit admin and elevated role holders quarterly
• Use Delegated Administration to scale group management
• Document what each custom role grants in the Role description field
• Never use the admin role for integrations—create a dedicated service account role

---

Conclusion

Roles are the language of ServiceNow security—ACLs, module visibility, catalog access, and UI controls all speak in roles. Groups are the efficient way to grant roles at scale. Master the distinction, design a clean hierarchy, and audit regularly, and your security model will scale cleanly as your instance grows.