ServiceNow role management is a critical topic that shows up constantly in certification exams — and it's trickier than it looks, because the rules around the admin role aren't just "roles grant permissions." There's a whole separate layer underneath called elevated privilege roles that governs who can grant what to whom.
In this article, we'll start from a real exam-style quiz question about the admin role, walk through why each option is right or wrong, and then zoom out to cover the full elevated privilege model — including how it applies beyond just security_admin, and what it means for building your own high-security roles.
The quiz question
Select 3 answers from the options below.
Correct answers
2. To grant the admin role to a user, the granting user must also have the admin role.
3. A user with only the admin role cannot grant the security_admin role to other users.
Incorrect / commonly misunderstood options
A non-admin user with only the security_admin role can add a user to a group that contains the security_admin role.
Detailed explanation
Let's walk through each statement and understand why it's correct or incorrect.
✔️ 1. Non-admin users cannot add users to a group containing the admin role
This statement is true. The admin role is highly privileged, and only users who already have the admin role can manage group membership for groups that contain it. This restriction directly prevents privilege escalation — without it, a user_admin could simply add themselves to an admin-carrying group instead of being granted the role directly.
Key takeaway: admin access is tightly controlled and cannot be indirectly granted via group management by non-admin users.
✔️ 2. To grant the admin role to a user, the granting user must also have the admin role
This statement is true. ServiceNow's documentation on elevated privilege roles states this explicitly: to grant the admin role to a user, the granting user must also have the admin role — a user with only the user_admin role cannot grant it, no matter how much user-management access they otherwise have.
Exam tip: don't confuse "can manage users" with "can grant any role." user_admin covers the former; the admin role's own grant is a special case carved out on top of that.
✔️ 3. A user with only the admin role cannot grant the security_admin role to other users
This statement is true, and it's the one that trips up the most exam-takers. security_admin is an elevated privilege role — the only one shipped in the base system. To grant it to someone else, the granting user must have the admin role and must first elevate their own session to security_admin before they can hand it out. Simply holding the admin role isn't enough on its own.
Why this matters: security_admin controls access to Access Control Lists (ACLs) and High Security Settings — the layer that decides who can read, write, or delete records on protected tables. ServiceNow deliberately adds friction here so that a compromised or careless admin session can't silently rewrite security rules.
❌ 4. A user with only the user_admin role can grant the admin role to other users
This statement is false. The user_admin role allows management of users and groups generally, but it does not allow granting the admin role specifically. Granting admin access always requires the admin role itself.
Common pitfall: assuming user_admin is powerful enough to grant every role just because it can touch the user and group forms.
❌ 5. A non-admin user with only the security_admin role can add a user to a group that contains the security_admin role
This statement is false. Group management for privileged roles still requires admin access — holding security_admin alone doesn't bypass that. And security_admin itself is session-based: it must be actively elevated, and it disappears again at logout or session timeout, so it was never meant to function as a standing, always-on privilege in the first place.
Important note: security roles are controlled more strictly than standard administrative roles, precisely because they gate the controls that everything else depends on.
Why elevated privilege roles exist at all
Users with the admin role can typically modify any record on any table. That's necessary for day-to-day administration, but it also means an admin session — potentially compromised, potentially just a careless click — could rewrite the very ACLs that control table security. Elevated privilege roles exist to put a manual speed bump in front of exactly that class of change.
Practically, that means:
- Elevated roles are not active by default, even for a user who technically holds them — they have to be manually elevated during the session, via User menu → Elevate Roles.
- Elevation is session-based: it lasts only for the current login session and is cleared on logout, session timeout, or manual de-elevation.
- If an elevated role contains another elevated role, holding one does not automatically elevate the other — each has to be elevated separately.
- Instance administrators can set a system property to force admins to always manually select their elevated role rather than defaulting to it.
Elevated privilege isn't just for security_admin
A detail a lot of exam guides skip: security_admin is the only role that ships as elevated privilege out of the box — but it isn't a special, hardcoded exception. Elevated privilege is a configurable attribute on the role record itself, which means administrators can mark any custom role as elevated privilege too.
On the Role form, the relevant fields are:
elevated_privilege— when true, a user must manually accept the role each session before its permissions become active. Defaults to false.grantable— whether the role can be granted independently, versus only being available bundled inside another role that contains it. Defaults to true.
This matters for GRC/IRM and platform architecture work specifically: if you're designing a role that governs something sensitive — say, control over integration credentials, or access to a compliance-sensitive table — flagging it as elevated privilege gives you the same "must actively opt in this session" protection that ServiceNow applies to security_admin, without needing to touch platform-level security code.
Role hierarchy at a glance
| Role | Can grant admin? | Can grant security_admin? | Requires elevation to use? | Can manage admin-carrying groups? |
|---|---|---|---|---|
| user_admin | No | No | No | No |
| admin (not elevated) | Yes | No | No | Yes |
| admin, elevated to security_admin | Yes | Yes | Yes (session-based) | Yes |
Common exam pitfalls on this topic
- Treating "has the admin role" and "is currently elevated" as the same thing — they're not. An admin who hasn't elevated to security_admin this session functionally cannot touch ACLs or grant security_admin, even though their role assignment hasn't changed.
- Assuming user_admin is a subset of admin with slightly fewer permissions — it isn't a scaled-down admin, it's a separate role with a specific, bounded scope (user and group management) that explicitly excludes granting admin or admin-group membership.
- Forgetting that elevation is per-role. If a custom role bundles security_admin inside it, elevating to the custom role does not automatically elevate security_admin — each elevated role inside it must be elevated on its own.
- Assuming security_admin is a permanent role assignment like most others. It's designed to be requested, used, and dropped within a session, not left "on" indefinitely.
Overall summary
Here's a consolidated view of the rules tested in this question:
- Non-admin users cannot manage admin group membership.
- The user_admin role cannot grant the admin role.
- To grant admin, you must already be admin.
- The admin role alone cannot grant security_admin.
- To grant security_admin, a user must have the admin role and elevate to security_admin before assigning it.
The elevation step is mandatory and time-bound, reinforcing ServiceNow's defense-in-depth approach to security administration.
Final thoughts
Questions like this test more than memorization — they test whether you understand ServiceNow's security and role hierarchy as a layered system, not a flat list of permissions. If you're preparing for CSA, CAD, or other ServiceNow certifications, the elevated privilege model is worth understanding beyond just security_admin: it's the same mechanism you'll reach for if you ever need to design your own high-security custom role.
Happy learning 🚀
This article reflects ServiceNow's documented elevated privilege role model, including the elevated_privilege and grantable role attributes. Exact menu labels (e.g. "Elevate Role" vs. "Elevate Roles") can vary slightly by release — verify against your own instance's User menu.
No comments:
Post a Comment