Roles, Groups, ACLs, and Application Access
Key Takeaways
- Assign application roles through groups whenever possible; direct user-role assignment is harder to audit and maintain.
- Module and application menu roles control navigation visibility, while ACLs control create, read, write, delete, and field access to the underlying data.
- A record operation on a sensitive field can require both a table-level ACL and a field-level ACL to pass; missing grants result in denied access.
- Within a single ACL, the required role, condition, and script gates all have to pass for that ACL to grant access.
- Application Access and cross-scope privileges decide what other scopes may attempt against an app's tables; user ACLs still apply afterward.
Security Is Part of the App Design
The ServiceNow CAD exam treats security as a design requirement, not a cleanup step after the table and form work is finished. A scoped application should have clear personas before records are exposed: requester, fulfiller, manager, application administrator, integration user, and any read-only auditor roles. Each persona should map to the smallest role set that supports the work.
A role is the named permission concept, but roles become maintainable only when assigned through groups. Give the x_app.requester role to a Requesters group, the x_app.reviewer role to a Reviewers group, and the x_app.admin role to the application administrators group. Then onboarding and offboarding happen through group membership instead of one-off role edits on user records.
Navigation Is Not Data Security
Application menus and modules help users find the app. Their Roles fields control whether navigation appears in the All menu or application navigator. That is useful, but it is not an authorization boundary for the records themselves.
| Control | What it protects | What it does not prove |
|---|---|---|
| Application menu role | Whether a menu group appears | That any table records are readable |
| Module role | Whether a link appears | That a bookmarked URL or API call is allowed |
| Table ACL | Whether a user can operate on records | That every sensitive field is visible |
| Field ACL | Whether a user can read or write one field | That the user can access the whole record |
A common CAD trap is a module that opens a list. The user may see the module because the module role matches, but the list can still be empty or blocked because the table's read ACL fails. The reverse also matters: hiding a module does not secure data if the table ACLs are broad.
ACL Gates: Table, Field, and Default Deny
An Access Control List (ACL) is a server-side rule for an operation such as create, read, write, or delete. For record ACLs, think in two layers. The table-level rule answers whether the user can perform the operation on records in the table. The field-level rule answers whether the user can perform the operation on a specific column. To read a sensitive field, the user must satisfy the relevant record access and the field access.
Inside one ACL, the checks are cumulative:
- The user has one of the required roles, or the role list is empty.
- The ACL condition evaluates to true for the current record context.
- The ACL script, if present, evaluates to true.
If no matching ACL grants the requested operation, access is denied. That default-deny model is why a custom table should receive explicit ACLs for the personas that need it instead of relying on UI hiding. Use conditions for readable logic, such as Assigned to is dynamic Me, and use scripts only when the condition builder cannot express the rule cleanly.
Application Access and Cross-Scope Boundaries
Scoped applications also have an application boundary. Application Access on a table controls whether scripts or web services from other scopes may read, write, create, delete, or access the table through web services. Runtime flags such as Can read and Can write are cross-scope gates; Can read is the foundation for other record operations.
For more restricted calls between scopes, ServiceNow can record or require cross-scope privilege decisions. The target application owner should approve only the operation and resource that are actually needed. Then, after scope access permits the attempt, ACLs still evaluate the user or execution context. The safe mental model is: scope gates first, then user/data gates.
How to Verify Security
Do not test only as admin. Impersonate each persona, open the menu, use direct list URLs, check forms, try list editing, and verify sensitive fields. A correct CAD answer usually names the right layer: group role for maintainability, module role for discoverability, table ACL for record access, field ACL for sensitive columns, and Application Access for cross-scope behavior.
A scoped Vendor Review app needs reviewers to open a Review Queue module, read review records, and leave the confidential_vendor_score field hidden unless they also have the x_vendor.score_viewer role. Another scoped finance app must query review records through server-side script. Which controls are part of a correct design?
Select all that apply