Users, Groups, Roles, and Access Control Lists

ServiceNow's security model has four pillars: users, groups, roles, and ACLs. Get this model right and the rest of platform administration follows. Get it wrong and you'll either expose data you shouldn't, or break workflows that should work.

Users (sys_user)

A user record represents an individual identity in your instance. Every person who can log in has a row in sys_user. Common fields:

• user_name (login id)
• first_name, last_name, email
• active (boolean — inactive users can't log in)
• locked_out (security lockout flag)
• manager (reference to another sys_user)
• department, company, location
• time_zone, date_format

Authentication is usually delegated to an external identity provider via SAML or OIDC (e.g., Okta, Microsoft Entra ID, Ping). The sys_user record is then provisioned via LDAP integration or just-in-time on first login.

Groups (sys_user_group)

A group is a named collection of users. Groups have two primary purposes:

1. Work assignment: A group can be the assignment target for incidents, change requests, catalog tasks, etc. "Service Desk", "Network Engineering", "Tier 2 Database Support".
2. Permission delivery: Roles can be granted to a group, and all members of that group inherit those roles.

Group membership is stored in sys_user_grmember — a join table between user and group.

Roles (sys_user_role)

Roles are the unit of permission. A role is a name (e.g., itil, admin, knowledge_admin, catalog_admin) that ACLs reference to grant access.

Common platform roles:

Roles are also hierarchical: granting itil_admin automatically grants itil because itil_admin contains itil. This containment is configured on the role record itself.

Two ways to assign a role

1. Direct assignment to a user via sys_user_has_role
2. Inherited assignment by being a member of a group that has the role assigned via sys_group_has_role

The latter is preferred — manage roles by group membership, not by editing individual user records. It dramatically simplifies leavers/joiners/movers.

Access Control Lists (ACLs)

An ACL is a permission rule. Each ACL specifies:

• Type: What is being protected (record, field, processor, etc.)
• Operation: read, write, create, delete
• Target: Which table and (optionally) which field
• Required roles: Which roles grant this permission
• Condition: A filter that must be true
• Script: Custom JavaScript that must return true

An ACL grants access when:

The user has at least one of the required roles
AND the condition evaluates to true
AND the script (if any) returns true

Example

ACL: incident.assigned_to / write with role itil and condition state != 6 (Resolved).

This means: "Users with the itil role can change the Assigned To field on an Incident only if the incident is not Resolved."

How ACL Evaluation Works

When a user requests an action (e.g., open a record, save a form), ServiceNow checks ACLs in this order:

1. Table-level ACL for the operation — fails fast if the user can't even read the table
2. Field-level ACLs — for each field, evaluated separately
3. Row-level / conditional ACLs — record-specific conditions

If any matching ACL grants access, access is granted. If no ACL grants access, access is denied — the platform is deny by default at the field level once you have a field ACL defined.

The Security Debugger

When an ACL is denying access you didn't expect (or granting access you didn't expect), use the Security Debugger: System Security > Debug Security Rules. It logs every ACL evaluation for the current session, showing you which rule fired, which role matched, and which condition passed or failed.

Every ServiceNow admin has used this tool. Make it your first stop for any permission troubleshooting.

Domain Separation (Brief)

Large enterprises and managed service providers use domain separation — segregating data inside the same instance for different tenants. Each record is stamped with a domain, and queries automatically filter by the current user's domain. This is an advanced topic (covered on CIS exams) but worth knowing about even at fundamentals level.

Practical Patterns

• Create a group per organisational team — assign work to groups, not individuals
• Create a role per logical permission set; avoid granting admin for routine work
• Test ACLs as a non-admin user (impersonate is your friend)
• Document role-to-group mappings; review them quarterly

Impersonate

The single most underused admin feature: impersonate user. From the user menu in the top right, you can take on another user's session to see exactly what they see. Always test new configurations and ACL changes by impersonating a representative end user before going to production.