Users, groups & roles in Administration

Users, groups & roles

Quick answer

Who can do what in ServiceNow comes down to three tables working together, users, groups and roles, with ACLs doing the actual enforcement. Get the relationship right and access is trivial to reason about and audit; get it wrong and you will chase permission bugs for weeks.

Key takeaways

The three tables
How they connect, the intended flow
Role containment
Testing access
Group types and nesting

The three tables

sys_user

People, and integration/service accounts.

sys_user_group

Groups, collections of users, usually by team or function. Can be nested.

sys_user_role

Roles, named bundles of permissions that ACLs check for.

The join tables matter too: sys_user_grmember links users to groups, and sys_group_has_role / sys_user_has_role link roles in.

How they connect, the intended flow

role  --granted to-->  GROUP  --has member-->  user
                                          (user inherits the group roles)

avoid: role --granted directly to--> user   // untraceable, hard to revoke

Grant roles to groups, add users to groups, and let users inherit. You can grant a role straight to a user, but you almost never should, group-based access is auditable, bulk-manageable, and easy to revoke by removing group membership.

Role containment

Roles can contain other roles. Granting one high-level role silently grants everything nested inside it. admin contains an enormous set, which is exactly why handing it out is dangerous. Key built-in roles:

admin

Superuser, effectively everything. Give sparingly.

itil

The standard fulfiller/agent role for ITSM work.

approver_user

Can act on approvals assigned to them.

ess

Employee self-service, the baseline end-user experience.

security_admin

Required to edit high-security ACLs (elevated role).

Testing access

Never assume, impersonate the user and try the action. Combined with Debug Security, impersonation tells you precisely which role or ACL granted or denied something. This is the fastest loop for validating an access model.

Group types and nesting

Groups carry a type (e.g. itil, catalog, approval) that controls where they can be used, for assignment, approvals, or catalog fulfilment. A group also has a manager and can be nested so a parent inherits members' visibility.

Common mistakes

Assigning roles directly to users, creating access no one can trace later.
Over-granting admin instead of the minimal role needed.
Forgetting that removing a user from a group revokes the inherited roles immediately.
Wrong group type, so a group never appears in the assignment or approval picker.

Practice challenge

+0 XPStreak ×0

Question 1 of 3

Security in ServiceNow is primarily...

Frequently asked questions

Security in ServiceNow is primarily?

Role-based. Roles, granted through groups, control access.

ACLs evaluate in the order?

Table, field, row. Table first, then field, then row.

The easiest way to manage access is at the level of?

The group. Group changes propagate to all members instantly.