Week 5 of 8
Roles and ACLs
ServiceNow decides who can read, write, create and delete through roles and access control lists. Upgrades and customizations change both. The defects that follow are rarely loud: an HR agent who can suddenly read cases from another country, or a fulfiller who can no longer close a task.
Xanadu added Deny-Unless ACLs and an option to deny access by default when an ACL is misconfigured or empty. Both supported families have them. If you use them, your access model has changed and needs testing.
This week: build the matrix and run it as real roles
- List your personas (ITIL fulfiller, HR agent, HR case manager, CSM agent, requester, approver) and their roles.
- For each persona, write expected allow and deny results for key tables and operations, including fields with sensitive data.
- Include negative tests. Proving a requester cannot read other people’s HR cases matters more than proving they can read their own.
- Run the matrix with impersonation or dedicated test users, never as admin, on test after every upgrade.
- Add AI agent tools to the matrix: an agent should not do what its user could not.
Number of the week
Xanadu
is the family that added Deny-Unless ACLs and a fail-closed option for misconfigured ACLs, so every supported instance can use them.
Source: ServiceNow docs, Access Management release notes (Xanadu)Use this week
- ServiceNow ACL & Role Test Matrix →
Persona by table by operation, expected versus actual, with negative tests and a mismatch count.
- Requirements Traceability Matrix →
Tie each access rule to the requirement or control it implements.
Next week: the instance is rarely what breaks. Integrations, spokes and ERP connections are.
Get the playbook in your inbox, one week at a time
Subscribe free and every template in the library is yours.