‹ All interview questions

Security

Your production incident management system is experiencing a critical issue: users with the 'Field_Manager'…

Senior · ServiceNow · Feb 2026

The question

Your production incident management system is experiencing a critical issue: users with the 'Field_Manager' role should have write access to all incident fields except 'assignment_group', but they're reporting they cannot edit any fields on incidents they create themselves. Meanwhile, users with the 'Assignment_Admin' role can edit the 'assignment_group' field without issues. You've confirmed the users have the correct roles assigned. Walk me through your diagnostic approach, explain what's likely happening, and provide the ACL configuration that would fix this while preventing similar issues in the future.

The Intent Behind This Question

This scenario tests whether you understand ACL evaluation order, the deny-by-default model, and the interaction between table-level and field-level ACLs. The key issue is likely that Field_Manager now fails a matching write ACL at either the table (record) level or the field level — they must pass both. Note there is no 'deny ACL' mechanism in ServiceNow; restriction comes from not being granted on the rule that matches. A junior developer might jump to creating ACLs without diagnosing; a senior architect diagnoses first, then designs with production safeguards.

Diagnostic Approach

Step 1: Enable ACL Debugging - Use the Security Debug module to trace which ACLs are evaluating and in what order. Check if the user can read the record (Table.none) but cannot write (Table.* or field-level). This narrows the scope to write permissions.

Step 2: Check ACL Matching Order - To write a field, the user must pass BOTH the first matching field-level rule (incident.assignment_group, falling back to incident.*, then *.*) AND the matching table-level (record) rule. More-specific rules stop processing of less-specific ones — if incident.assignment_group rules exist, incident.* is never consulted for that field. When several rules match at the same point, passing any one is enough (OR); if nothing matches at all, access is denied by default.

Step 3: Identify Which Rules Actually Match - A field with no ACL of its own falls back to the wildcard rules (incident.*, then *.*). A recently added restrictive incident.* write ACL that Field_Manager fails would block every field at once — exactly the reported symptom. The 'assignment_group' field has its own explicit ACL granting Assignment_Admin, which is why that role still works.

The Solution

// ACL 1: Record-level read (row access)
Type: record | Operation: read
Name: incident [table] -- None [field]
Roles: Field_Manager, Assignment_Admin

// ACL 2: Record-level write (row access)
Type: record | Operation: write
Name: incident -- None
Roles: Field_Manager, Assignment_Admin

// ACL 3: Field-level write for all other fields
Type: record | Operation: write
Name: incident -- * (wildcard field)
Roles: Field_Manager, Assignment_Admin

// ACL 4: Field-level write on assignment_group
Type: record | Operation: write
Name: incident -- assignment_group
Roles: Assignment_Admin ONLY

// Field_Manager passes ACLs 1-3 but fails ACL 4, so they can edit
// every field EXCEPT assignment_group. There is no "deny" ACL and
// no "return false" trick — you exclude a role by simply not
// granting it on the specific field rule, which (being more
// specific) displaces the wildcard for that field.

Senior Considerations

  • No Deny Mechanism - When multiple ACLs match the same object and operation, passing ANY ONE grants access (OR) — so you can never 'deny' a user who passes another matching rule. Restriction works by making the specific field ACL the only matching rule for that field and not granting the excluded role on it.
  • Explicit Field ACLs for Sensitive Fields - Create explicit field-level ACLs for sensitive fields; otherwise they inherit the wildcard (incident.* / *.*) behavior, which is usually broader than intended.
  • Avoid Wildcard Risks - Table.* grants all fields at once but is dangerous for sensitive data. Consider field-level ACLs for audit trails, passwords, or encrypted fields instead.
  • Testing Strategy - Impersonate both roles in a dev instance and test form load, field visibility, and save operations. Check browser console for ACL-related errors. Use impersonation, not role assignment switching, to avoid session pollution.
  • Migration and Audit - Document ACL intent in the description field. When migrating across environments, field-level ACLs are frequently missed. Create an ACL checklist: table-level reads, table-level writes, and explicit field-level rules for sensitive fields.
  • Production Safeguard - Implement a before-save business rule that logs ACL denials for audit purposes. This catches configuration drift and user complaints with evidence.