3.3 Users, Groups & Roles
Key Takeaways
- A User [sys_user] gains access by being a member of Groups [sys_user_group] and by being granted Roles [sys_user_role], directly or through group membership.
- Roles can contain other roles; a user granted a containing role automatically inherits all contained roles (role inheritance), such as the admin role implying many others.
- Impersonation lets an administrator temporarily act as another user to test access and collaboration views without knowing that user's password, and the action is logged.
- Group-based assignment, Assignment Rules, and delegation route work to the right people; delegation lets a user temporarily receive another user's approvals and notifications.
- Roles drive contextual security: Access Control Lists (ACLs) evaluate the operating user's roles, so user/group/role design directly governs what collaborators can see and do.
Why User, Group, and Role Design Matters
Collaboration only works if the right people can see and act on the right records. On the CSA exam, Users, Groups, and Roles is the access backbone behind notifications, assignment, knowledge, and the catalog. Misconfiguring this model is the most common cause of "the user cannot see the record" support tickets.
Users, Groups, and Roles
| Object | Table | Purpose |
|---|---|---|
| User | sys_user | A person (or service account) who logs in |
| Group | sys_user_group | A collection of users, used for assignment, approvals, and bulk role grants |
| Role | sys_user_role | A named permission set referenced by ACLs, UI features, and applications |
A user can receive a role two ways:
- Directly — granted on the user record (
sys_user_has_role). - Through a group — every member of a group inherits the roles attached to that group. This is the recommended, scalable approach: change the group's roles once and every member updates.
Role Inheritance (Role Containment)
Roles can contain other roles. When a role is granted, the user also receives every role nested inside it. The classic example: the admin role contains many roles (such as those for catalog, knowledge, and reporting), so an admin can do almost everything without being granted each role individually.
The practical exam point: granting a high-level role can silently grant broad access through inheritance, so administrators should grant the narrowest role that meets the need.
Assignment Rules and Delegation
Assignment Rules automatically set the assignment group and optionally the assigned to user when a record matches a condition (for example, route all Network incidents to the Network group). They reduce manual triage and keep collaboration flowing to the right team.
Delegation lets one user temporarily act on behalf of another for specific responsibilities. On a user's Delegates related list, an administrator or the user defines a delegate and a date range, choosing which capabilities transfer:
| Delegation Option | Effect |
|---|---|
| Approvals | Delegate can approve/reject in the delegator's place |
| Assignments | Delegate receives work assigned to the delegator |
| CC Notifications | Delegate is copied on the delegator's notifications |
| Meeting invitations | Delegate receives the delegator's meeting invites |
Delegation is time-bound and is the supported way to cover vacations without sharing credentials.
Impersonation
Impersonation lets an administrator temporarily operate the instance as another user to verify exactly what that person can see — essential when troubleshooting collaboration and visibility issues. Key facts the exam tests:
- No password is required; only users with the right role can impersonate.
- The session reflects the target user's roles, groups, and ACL outcomes.
- The action is logged for audit, and the admin ends it by switching back.
- Impersonation is the fastest way to confirm an ACL or User Criteria change works before involving the end user.
Contextual Security and Collaboration
Users, groups, and roles feed directly into contextual security — the layered model that decides record and field visibility. The order of evaluation matters: ServiceNow checks high-level security (like the Contextual Security Manager and table/field Access Control Lists (ACLs)) against the operating user's effective roles.
| Layer | Driven By | Effect on Collaboration |
|---|---|---|
| Role | Direct + group + inherited roles | Determines which ACLs the user satisfies |
| ACL (record/field) | Role + condition + script | Decides if a collaborator can read/write a field or record |
| User Criteria | Users, groups, roles, company | Gates Knowledge Base and Catalog access |
Because an ACL grants access when its conditions pass and the user has at least one of its required roles, sound group/role design is what actually makes collaborative features — shared queues, knowledge, catalog — work safely. This connects Section 3.3 back to the notifications and task work in 3.1 and 3.2.
What is the recommended, most scalable way to give 40 service-desk users the same set of roles?
An administrator is granted the admin role. Why can they perform catalog, knowledge, and reporting actions without each specific role being explicitly granted?
A user reports they cannot see a record other team members can see. What is the fastest supported way for an administrator to confirm what that user actually sees?
Which capabilities can be transferred when configuring delegation for a user going on leave? Select all that apply.
Select all that apply