🔐 ServiceNow — Identity & Access Management

ServiceNow Admin & Developer Guide · Digital Kimya

Understanding how ServiceNow manages identity and access is foundational to any ITSM implementation. A misconfigured access model causes two types of pain: over-access (security risk, audit failure) and under-access (users blocked, service desk overwhelmed). This guide covers every layer — from the sys_user record to ACL evaluation order.

Diagramme interactif

The Access Model at a Glance

ServiceNow access works through a three-layer stack:

User ──member of──► Group ──has roles──► Role ──evaluated by──► ACL

Each layer adds a level of control. The most common mistake is short-circuiting this chain by assigning roles directly to users — see the Anti-Pattern section below.

Core Objects

sys_user — The User Record

Every person or technical system that interacts with ServiceNow has a sys_user record. Key fields:

Example: jdupont is a user record with active = true, belonging to the group IT Support L1. She never has roles assigned directly — they come through her group membership.

sys_user_group — The Group

Groups cluster users around a business function. A group can simultaneously serve two purposes:

• Security group: has roles → members inherit those roles automatically
• Assignment group: routes tasks (incidents, changes, requests) to the right team

Example: The group Change Advisory Board has the role change_manager. Any user added to this group immediately gains change approval permissions — no individual role assignment needed. When they leave the CAB, removing them from the group revokes access instantly.

sys_user_role — The Role

A role is a named permission that grants access to modules, applications, or data. Roles can contain other roles (nested inheritance), which means granting one role can implicitly grant many others.

Role inheritance example:

change_manager
  └── itil
        ├── approval_user
        └── calendar_user

Granting change_manager to a group gives members all four roles.

⚠️ Anti-Pattern — Direct Role Assignment

User ──────────────────────────────► Role   ← AVOID THIS
     (direct assignment, red arrow)

Why it's dangerous:

1. Audit nightmare: "Who has admin access?" requires checking both groups AND individual users
2. Stale access: when someone changes roles in the organisation, their individual assignments don't automatically update
3. No single source of truth: access model splits across two locations
4. CSA/CIS exam trap: this is a classic exam question — direct role assignment bypasses group governance

Exception: Service accounts and technical integration users (REST API callers, integration middleware) can legitimately have roles assigned directly, since they don't change function.

sys_security_acl — Access Control Lists

An ACL rule defines who can do what on which data. Every data access in ServiceNow triggers ACL evaluation.

ACL Evaluation Order

1. Role check    — does the user have the required role?
        ↓
2. Condition     — does the record match the condition (e.g. state = Active)?
        ↓
3. Advanced script — custom JavaScript returning true/false
        ↓
No match → ACCESS DENIED (deny by default)

Critical rule: If no ACL matches, access is denied by default. You must explicitly grant access — there is no "allow all" fallback.

ACL Levels

ACL Operations

Example ACL — Field level:

→ Only admins can see the salary field of the incident caller. Everyone else sees the field as blank.

Assignment Group vs Security Group

These look identical (sys_user_group) but serve different purposes — confusing them is a common implementation mistake:

Example: An incident categorised as Network is automatically assigned to the group Network Ops via an Assignment Rule. The team members can work the incident because they're also a security group with the itil role.

Implementation Roadmap

Quick Reference

// Check a user's effective roles in a Background Script
var user = new GlideRecord('sys_user');
user.get('user_name', 'jdupont');
 
var roles = user.getValue('roles');
gs.info('Direct roles: ' + roles); // Should be empty if group-based model is correct
 
// Check via GlideSystem
gs.hasRole('itil');           // true/false for current session user
gs.hasRole('change_manager'); // true/false

Common Mistakes & Fixes

Part of the Digital Kimya (opens in a new tab) ServiceNow Guide Series — Scripts & Logic · Tables & Data · Deployment