🔧 Part 2 · Topic 1 of 3

Users, Groups & Roles

⏱ ~50 min read 🎯 Exam weight: Part 2 = 11% 📋 ServiceNow CSA

Access control in ServiceNow is built on three interlocking layers: Users, Groups, and Roles. Understanding how these interact is fundamental to both the exam and real-world administration. This topic covers how to create and manage users, organise them into groups, and use roles to grant the right permissions to the right people.

Section 1

The Three-Layer Access Model

Core Concept: ServiceNow uses Users → Groups → Roles for access control. A user gains permissions through roles. Roles can be assigned directly to a user, or inherited automatically when the user joins a group that carries that role. ACLs (Access Control Lists) then evaluate those roles at runtime to decide what the user can see or do.

👤 User (sys_user)

Has a User ID,
email, active flag

→

👥 Group (sys_user_group)

Membership via
sys_user_grmember

→

🔑 Role (sys_user_role)

Assigned directly or
via group membership

→

✅ Permissions

Evaluated by ACLs
at runtime

A user can receive a role via either path — direct assignment or group membership — and both are checked equally by the ACL engine.

Key Tables in the Access Model

sys_user All user accounts. One record per person (or service account).

sys_user_group All groups. Each group has a name, manager, optional email, and parent.

sys_user_role Role definitions. Each role may contain other roles (role inheritance).

sys_user_grmember The join table: which user belongs to which group.

sys_user_has_role Direct user-to-role assignments (not via group). Also records inherited roles for display.

Section 2

Users (sys_user)

A user record represents an individual human or service account in ServiceNow. Navigate to User Administration > Users > New to create one. Every field on the user record has a purpose — the exam tests several of them.

Key Fields on the User Record

Field	Purpose	Notes / Exam Detail
`User ID`	Login name — unique identifier used to sign in	Usually firstname.lastname. This is NOT the display name.
`First / Last Name`	Combined to form the display name shown in UI	What you see in lists and assignments.
`Email`	Used for notifications and as an alternate login	Must be unique across the instance.
`Active`	Boolean — controls whether the user can log in	Setting to false prevents login; does NOT delete records.
`Locked out`	Set automatically after 5 failed login attempts	Admin must uncheck this field to unlock the account.
`Password`	Login credential	Stored hashed. Admins can reset but never see it.
`Time zone`	User's local time zone for date/time display	Overrides the instance-level default time zone.
`Language`	UI language preference	Requires the language plugin to be activated.
`Department`	Organisational unit the user belongs to	Reference to `cmn_department` table.
`Manager`	Defines the reporting / approval hierarchy	Reference field back to `sys_user`. Used in approval flows.
`Calendar integration`	Links to Outlook or Google Calendar	Enables on-call schedule sync.

User Types

Regular User

A human who logs in to use ServiceNow. Has an Active flag set to true. Requires a license if they are a fulfiller (ITSM agent).

Service Account

A non-human account used by integrations and scripts (e.g., a middleware tool calling the REST API). Active = true, but no human logs in with it. Often has a specific role for the integration only.

External / Guest User

Users who access the Service Portal or Community but are not internal staff. Usually limited to the catalog or itil role at most.

Exam Tip — Active Flag: Setting Active = false does not delete the user's records, assignments, or history. It simply prevents login. Always deactivate users when they leave — rarely (almost never) delete them, because deletion would break audit trails and historical records.

User ID vs Display Name: These are two distinct fields. User ID (login name) might be john.smith. The Display Name (First + Last) is John Smith. Searches in lists often use the display name; login uses the User ID. The exam will test that you know the difference.

Section 3

Groups (sys_user_group)

Groups are collections of users who share similar responsibilities or work in the same functional area. They are used everywhere in ServiceNow: routing, assignment, notifications, access control, and approval flows.

What Groups Do

Role Inheritance

Roles assigned to a group are automatically granted to every current and future member. This is the preferred way to manage permissions at scale.

Ticket Assignment

Incidents, problems, and changes are assigned to a group (the Assignment Group). Agents in that group then pick up or are assigned the work item.

Email Routing

A group can have a single group email address. Inbound email sent to that address creates or updates records and routes to the group.

Notifications

Notification rules can target a group, sending alerts to all members when specific events occur on a record assigned to that group.

Key Fields on the Group Record

Field	Purpose	Notes
`Name`	Display name for the group	Should be descriptive, e.g., "IT Support - Tier 1"
`Manager`	User responsible for managing this group	Reference to `sys_user`. Gets the `group_manager` role capability.
`Email`	Group inbox for inbound email routing	Used by the inbound email action engine to route to this group.
`Include members`	Roll up members of child groups into this group	Useful for parent groups that should see all sub-group work.
`Parent`	Creates a group hierarchy (group of groups)	Enables organisational structure without duplicating membership.
`Roles` (related list)	Roles granted to ALL members of this group	Adding a role here is the preferred, scalable approach.
`Members` (related list)	Users in this group (`sys_user_grmember`)	Membership change is immediate — roles apply instantly.

Exam Critical — Group Roles Scale: Adding a role to a group grants that role to ALL current AND future members of the group. This is the recommended approach for role management at scale — not user-by-user assignment. The exam frequently tests this distinction.

Analogy — Think of Groups as Job Departments: When you assign the itil role to the "IT Support Group", every new hire added to that group automatically gets the correct permissions from day one. When someone leaves the department, remove them from the group and all role access is revoked immediately — no manual cleanup needed.

Assignment Groups vs Support Groups

These are not different types in the database — they are the same sys_user_group records used in different contexts:

Term	Where it Appears	What it Does
Assignment Group	Incident, Problem, Change, Task forms	The group responsible for resolving this specific work item. Agents in this group see it in their queue.
Support Group	Routing / assignment rules configuration	Configures which group receives incoming requests based on category, service, or other criteria.

A single group record can serve as both an Assignment Group on tickets and a configured Support Group in routing rules simultaneously.

Section 4

Roles (sys_user_role)

Roles are named permission sets that the ACL engine evaluates at runtime. They can be assigned directly to users or via groups. Crucially, roles can contain other roles — this is called role inheritance or role containment.

Core Roles Every CSA Must Know

Role	What It Grants	Access Level
admin	Everything — full instance administration	Bypasses ALL ACL checks. Use only for admins.
security_admin	Manage ACLs, security policies, elevated operations	Security configuration. Required for ACL edits even for admins.
itil	Handle incidents, problems, changes, tasks	Standard ITSM agent baseline role.
itil_admin	Admin ITSM processes — configure, not just use	Contains `itil`. Manages categories, templates, etc.
catalog_admin	Create and manage all service catalog items	Full catalog configuration access.
catalog	Browse and submit service catalog requests	End-user access. Low privilege.
user_admin	Create, edit, and manage user accounts	User and group management (not full admin).
knowledge	Create, edit, and publish knowledge base articles	Knowledge management role.
report_group	Create reports and share with groups	Reporting access — read data, build reports.
survey_admin	Create, manage, and deploy surveys	Survey tool administration.

Exam — The itil Role: The itil role is the baseline for all IT agents. It grants access to incidents, problems, changes, and ITSM-related tasks. It does not grant admin access, configuration rights, or catalog management. Most frontline support users get itil plus a small set of additional roles.

Warning — The admin Role: The admin role bypasses ACLs completely. This means a user with admin can read and write any table, any field, any record regardless of security rules. Never assign admin to regular users. Use itil combined with specific functional roles instead. Fewer than 5 people should hold admin in a production instance.

Role Inheritance (Containment)

A role can contain other roles. When a user is granted the parent role, they automatically receive all the contained (child) roles. This creates a hierarchy of permissions.

itil_admin

Parent role

contains ▶

itil

Child role (auto-granted)

contains ▶

ITSM permissions

Effective access

You can view role containment on any role record in the Contains Roles related list. To see the full inheritance chain, click into each contained role.

Section 5

Assigning Roles

There are three paths through which a user can receive a role. Understanding each — and which is preferred — is a common exam topic.

Direct Assignment — User Record

Navigate to the user record. Open the Roles tab (related list). Click Edit to add a role directly to this individual user.

Table: sys_user_has_role · Relationship: user → role

RECOMMENDED Via Group Membership

Navigate to the group record. Open the Roles tab. Add the role to the group. Every current and future member automatically inherits this role — no per-user work needed.

Table: sys_user_grmember · Roles flow from group → all members

Via Role Containment (Inheritance)

When a user is granted a parent role (directly or via group), all roles contained within that parent role are automatically granted too. No explicit assignment needed for child roles.

Table: sys_user_role · Contains Roles related list on the role record

Best Practice — Always Prefer Groups: Assign roles to groups, not to individual users. Groups scale (add a new person to the group — done), groups are auditable (see exactly who is in each group), and group membership is easier to bulk-manage. Direct role assignment creates a maintenance burden and is harder to audit.

Finding Who Has a Role

You may need to audit which users hold a particular role. Two common methods:

Via the Role Record

Navigate to User Administration > Roles, open the role record, and look at the Contains Users related list. This shows all users who currently hold this role (directly or via group).

Via Table Query

Navigate directly to sys_user_has_role.list in the URL bar. Filter by the desired role. This gives the raw join table with explicit vs. inherited flags.

Section 6

Elevated Privileges & security_admin

Some operations in ServiceNow require an additional layer of access beyond standard admin — the security_admin role. This enforces separation of duties even among administrators.

Why security_admin Exists

Modifying ACL rules is a high-impact operation. Requiring a separate security_admin role ensures that even a compromised admin account cannot silently change security rules without an explicit, audited privilege elevation.

What it Controls

Creating or editing ACL records, viewing certain security audit logs, and accessing the Security Manager module. Regular admins without this role will see these areas as read-only or hidden.

Session Elevation

Elevation to security_admin is session-based — it must be explicitly requested each session and expires when the session ends. It is not always-on even for users who hold the role.

Warning — Protect security_admin: The security_admin role is the most powerful role in ServiceNow beyond admin. Assign it to the absolute minimum number of people. Audit its use regularly via System Logs > Security. Treat elevation events as sensitive security events.

Section 7

Common Exam Traps

These are the specific scenarios the CSA exam is known to test. Read each one carefully.

Trap 1 — Dual Role Paths

A user can hold a role both directly and through a group simultaneously. ServiceNow checks if they have the role via either path — both count equally. The exam may ask what happens in this case.

Trap 2 — Removing from Group

Removing a user from a group immediately removes all roles they inherited through that group — unless they also have those same roles via direct assignment. The removal takes effect in real time.

Trap 3 — Active vs Deleted

Setting Active = false prevents login but preserves all history, records, and assignments. Deleting a user removes the record entirely. The exam almost always expects you to deactivate, not delete.

Trap 4 — admin Bypasses ACLs

The admin role does not "have" all ACLs — it bypasses them entirely. This means ACL debugging should be done with a non-admin test account that only holds the roles being tested.

Trap 5 — User ID ≠ Display Name

User ID (e.g., john.smith) is the login credential. Display Name (First + Last Name, e.g., "John Smith") is what appears in the UI. They are separate fields and can be different.

Trap 6 — Viewing All Roles

To see all roles a user currently holds (including those from groups), go to the user record and open the Roles tab. It shows both direct and group-inherited roles clearly labelled.

Checking a User's Full Role Set: On the user record, the Roles related list tab shows every role the user has — direct assignments AND inherited group roles. Roles inherited from groups are marked with the group name in the list. This is the single best place to audit a user's access.

📌 Quick Reference — Users, Groups & Roles

Three layers: User (sys_user) → Group (sys_user_group) → Role (sys_user_role)
Group roles: Assigning a role to a group grants it to ALL members, current and future
Best practice: Assign roles via groups, not directly to individual users
Active = false: Prevents login only — does not delete records or history
User ID: Login name (e.g., john.smith) — distinct from Display Name (John Smith)
admin role: Bypasses ACLs entirely — never assign to regular users
itil role: Baseline for ITSM agents — incidents, problems, changes access
security_admin: Required to modify ACLs — session-based elevation
Role containment: Parent role automatically grants all contained child roles
Remove from group: Immediately removes all group-sourced roles (unless also directly assigned)
Key tables: sys_user, sys_user_group, sys_user_role, sys_user_grmember, sys_user_has_role

← Part 1 Last Topic Tables & Dictionary →