Users, groups & roles

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.

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

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.

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:

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.

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.

• 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.