Access Control Rules (ACLs) Flashcards
7 cards from real CSA practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.
Read the first 7 Access Control Rules (ACLs) flashcards as text
A field ACL exists for 'incident.caller_id' with the read operation. What does this ACL specifically control?
Answer: Whether the Caller ID field appears on the Incident form
A field-level read ACL on 'incident.caller_id' controls visibility — whether users can see the field's value on forms and lists.
What happens to a field protected by a write ACL that a user fails?
Answer: The field appears but is read-only for that user
When a user fails a field-level write ACL, the field remains visible but becomes read-only — they can see but not edit the value.
Which ACL name format would restrict access to the 'priority' field on the Problem table?
Answer: problem.priority
Field-level ACLs in ServiceNow use the format 'table_name.field_name', so 'problem.priority' targets the priority field on the Problem table.
What is the function of the 'gsftNavigation.openRecord' check in ACL scripts?
Answer: It is not a valid function in ACL scripts
'gsftNavigation.openRecord' is not a recognized ACL script function; ACL scripts use GlideRecord methods and standard ServiceNow APIs instead.
When troubleshooting ACL issues, what does the Security Debug plugin provide that standard logging does not?
Answer: Real-time display of which ACLs are being evaluated for each request
The Security Debug plugin adds a debug panel showing exactly which ACLs are evaluated and whether they pass or fail for each page load or record access.
How does ServiceNow handle ACL evaluation for records returned in a GlideRecord query run in a background script?
Answer: ACLs are enforced based on the session user running the script
In background scripts, ACLs are evaluated in the context of the user who initiated the script session, unless elevated privileges are explicitly used.
What is the recommended practice when an ACL needs to grant access based on the logged-in user's department matching the record's department?
Answer: Use an ACL script condition comparing gs.getUser().getDepartmentID() to current.department
An ACL script using gs.getUser().getDepartmentID() compared to current.department dynamically evaluates the user-to-record relationship at access time.