Security & Restricting Access
This domain covers ACLs, roles, application scope security, data policies, and developer-level security practices. It tests your ability to protect data and restrict access at every level.
ACLs — Deep Dive for Developers
ACLs are the backbone of ServiceNow security. For the CAD exam, you need to understand the full evaluation chain, scripted ACLs, and how to debug access issues.
ACL Types by Granularity
| Level | Format | Controls | Example |
|---|---|---|---|
| Table | table_name | Access to all records/fields | incident (read) |
| Field | table_name.field_name | Access to specific field | incident.priority (write) |
| Row | Condition on table ACL | Which records are visible | Active = true AND group = mine |
| Wildcard | * | Default for all tables | * (read) — global fallback |
ACL Evaluation Rules
- Check field-level ACLs first (most specific).
- Then check table-level ACLs.
- Then check parent table ACLs (inheritance).
- Then check wildcard (*) ACLs.
- ALL matching ACLs must evaluate to TRUE for access.
- If NO ACL matches, access is DENIED (deny by default).
Scripted ACL Conditions
ACLs support scripted conditions using the 'answer' variable. Set answer = true to grant access, answer = false to deny.
- answer — Set to true/false to control access.
- current — The record being accessed.
- gs.getUser() — The current user object.
- gs.hasRole('role_name') — Check if user has a role.
- gs.isInteractive() — True if a user is accessing via UI (not API/script).
ACLs are deny-by-default. If no ACL exists for a table, access is denied (unless the user is admin). ALL matching ACLs must pass. A single failing ACL blocks access even if 10 others pass. The admin role bypasses all ACLs entirely.
Users in the 'hr_staff' role should be able to read all HR cases, but only write to cases assigned to their group. How do you configure this?
Create two ACLs on the hr_case table: (1) Read ACL — requires role 'hr_staff' with no additional conditions. This allows all HR staff to read all cases. (2) Write ACL — requires role 'hr_staff' with condition: Assignment Group is one of user's groups. This restricts writing to only cases assigned to their group.
Custom Roles & Role Hierarchy
For custom applications, developers should create custom roles rather than relying on built-in roles. Role hierarchy allows roles to contain other roles.
Role Best Practices
- Create application-specific roles (e.g., x_myapp.user, x_myapp.admin, x_myapp.manager).
- Role hierarchy — A parent role inherits all permissions of its child roles.
- Example: x_myapp.admin contains x_myapp.user. Anyone with admin role gets user permissions too.
- Never use the global 'admin' role for application-specific access.
- Document role requirements for each table and field.
Role Hierarchy Example
| Role | Contains | Permissions |
|---|---|---|
| x_myapp.admin | x_myapp.manager | Full CRUD + configure |
| x_myapp.manager | x_myapp.user | Read all + write own group |
| x_myapp.user | — | Read own + create new |
When a role CONTAINS another role, users with the parent role automatically inherit all child role permissions. This is called 'role elevation' or 'role hierarchy'. Design roles from least privilege (base user) upward. The exam tests whether you know to create custom roles vs. using built-in ones.
Application Scope Security
Scoped applications have built-in security boundaries. Cross-scope access must be explicitly configured on each table and script.
Application Access Controls
- Can read — Other scopes can query this table.
- Can create — Other scopes can insert records.
- Can update — Other scopes can modify records.
- Can delete — Other scopes can delete records.
- Caller Access — Controls which scripts from other scopes can call Script Includes in this scope.
- Allow access to this table via web services — Enables REST/SOAP API access.
By default, a scoped application's tables are NOT accessible from other scopes. You must explicitly enable cross-scope access for each table. This is a major exam topic — know the Application Access settings.
Data Policies for Developers
Data Policies enforce data integrity at the server level, ensuring data quality regardless of whether records are created via the UI, API, Import Sets, or scripts.
When to Use Data Policies
- When a field MUST be populated regardless of the entry point.
- When a field must be read-only to prevent modification through APIs.
- When UI Policies alone are insufficient (bypassed by API/import).
- When the same rules must apply across all interfaces (UI, portal, API, import).
The exam presents scenarios where data integrity is compromised because rules only exist as UI Policies. The correct answer is usually 'Add a Data Policy' because it enforces the rule server-side. Remember: UI Policy = client-side only. Data Policy = server-side, cannot be bypassed.
Debugging Security Issues
When users report access issues, developers need tools to diagnose the problem. ServiceNow provides several debugging mechanisms.
Debugging Tools
- Security Diagnostics — Navigate to a record, add '&sysparm_security_debug=true' to the URL. Shows which ACLs were evaluated and their results.
- Impersonation — Impersonate the affected user to see their exact experience.
- Session Debug — Enable debug modules to see real-time security evaluations in the debug log.
- ACL test — Navigate to System Security > Debug Security. Shows ACL evaluation for specific operations.
- System Logs — Check sys_log for security-related errors.
The Security Diagnostics URL parameter (&sysparm_security_debug=true) is the fastest way to see why a user cannot access a record or field. It shows every ACL evaluated and whether it passed or failed. This is a commonly tested debugging technique.
Key Takeaways
- ACLs are deny-by-default. ALL matching ACLs must pass. No matching ACL = denied.
- Use &sysparm_security_debug=true to debug ACL issues on any form.
- Create custom roles for custom applications. Never rely on the global admin role.
- Role hierarchy: parent roles inherit all child role permissions automatically.
- Scoped application tables are NOT accessible cross-scope by default. Enable explicitly.
- Data Policies enforce rules server-side. UI Policies enforce client-side only.
- Scripted ACLs use the 'answer' variable — set to true/false to grant/deny.
Community-created study aids. Not official ServiceNow exam content.