Start with the requirement—not the feature name
Ask what must be controlled. If the requirement says who can access a record, field or operation, start with an Access Control List. If it describes how a form should behave for an interactive user, consider a UI Policy. If it describes data integrity across entry channels, consider a Data Policy.
Access Control Lists: decide whether access is allowed
An ACL associates an operation—such as create, read, write, delete or execute—with a protected ServiceNow object. The rule can evaluate required roles, conditions and a script. The effective decision can involve more than one applicable rule, especially when table-level and field-level access are both relevant.
Use ACLs for requirements such as “only HR case agents may read this table,” “requesters may see only their own records,” or “only managers may update the approval field.” Design for least privilege and test with a representative non-admin user.
If the answer must remain secure even when a request comes from a list, API or another interface, do not rely on a form setting. Use access controls.
ACL evaluation checklist
- Identify the requested operation and protected table or field.
- Identify the user, roles and record context.
- Check all applicable table and field rules—not only the rule you recently changed.
- Impersonate an appropriate test user and use ServiceNow security debugging.
- Confirm both the intended allow case and a case that must be denied.
UI Policies: control the form experience
A UI Policy evaluates conditions on a form and applies actions that can make fields mandatory, visible or read-only. It is usually easier to maintain than a client script for straightforward form behavior and can reverse its actions when conditions no longer match.
For example, when the category becomes “Hardware,” a UI Policy can show and require an asset field. This improves user guidance, but it does not prevent an integration from writing the record without that value and it does not protect the field from unauthorized access.
Guide the agent without pretending it is security
When an incident moves to Resolved, require resolution notes on the form. Use a UI Policy for the form behavior. If records arriving through integrations must also contain resolution notes, add an appropriate server-side data-integrity control.
Data Policies: keep saved data consistent across channels
A Data Policy enforces mandatory or read-only field behavior when records are inserted or updated, including paths that may not use the normal form. That makes it suitable when imported, integrated and interactively entered data must follow the same requirement.
Data Policies do not answer whether a user is authorized to read or change a record. They enforce a data rule. If a requirement includes both authorization and completeness, you may need an ACL and a Data Policy, each serving its distinct purpose.
Decision sequence
1. Is it about authorization? Use ACL design. 2. Is it only form behavior? Use a UI Policy. 3. Must the data rule survive imports or web services? Use a Data Policy or another suitable server-side integrity mechanism.
Real-world scenario: records bypass a mandatory form field
Situation: Support agents create incidents in the ServiceNow form, while a monitoring integration creates incidents through an API. A UI Policy makes “Business service” mandatory when impact is high. Agent-created records comply, but API-created high-impact incidents arrive without a business service.
Identify the execution path
The UI Policy runs for the interactive form. The integration does not use that form, so the browser rule cannot protect imported data.
Enforce the data requirement
Use a Data Policy or an appropriate server-side validation design so the requirement applies to both interactive and integrated inserts.
Keep authorization separate
Use ACLs to decide who can read or change the business-service field. Mandatory data and access security are different concerns.
This is an illustrative training scenario, not a customer incident or production screenshot.
Troubleshoot the control that actually applies
“The field is hidden, but a user still accessed its value”
A UI Policy only changed the form presentation. Review field and table ACLs, then test through the relevant interface with a non-admin account.
“The UI Policy works for agents but imports contain incomplete data”
The import path bypasses the interactive form. Review Data Policy or other server-side validation requirements and confirm how rejected records will be handled operationally.
“I added an ACL, but access is still denied”
Check other applicable table and field ACLs, required roles, conditions, scripts, inheritance and the exact operation. Use ServiceNow’s security debugging rather than repeatedly broadening permissions.
“Administrators can do it, so the rule looks correct”
Administrator behavior can mask the experience of ordinary users. Test the intended personas and include both positive and negative cases.
Common CSA exam mistakes
- Choosing a UI Policy when the requirement is security.
- Choosing an ACL when the requirement is only to guide a user on a form.
- Assuming a mandatory UI field protects imports and integrations.
- Troubleshooting one ACL without considering other applicable table and field rules.
- Testing only with an administrator account.
- Combining authorization and data integrity into one vague requirement.
Frequently asked questions
What is the main difference between an ACL and a UI Policy in ServiceNow?
An ACL controls whether a user can access an object or operation such as reading or updating a table, record or field. A UI Policy changes form behavior such as visibility, mandatory state or read-only state. A UI Policy is not a security control.
When should I use a Data Policy instead of a UI Policy?
Use a Data Policy when a mandatory or read-only rule must apply to data regardless of how it enters ServiceNow, including imports and web services. Use a UI Policy when the requirement is specifically about interactive form behavior.
Can a UI Policy protect sensitive fields?
No. Hiding or making a field read-only in the browser does not securely prevent access through other interfaces. Protect sensitive records and fields with appropriately designed ACLs.
What happens when more than one ACL matches?
ServiceNow evaluates the applicable access controls for the requested object and operation. Table and field access may both matter, and the user must satisfy the required checks. Administrators should test the effective result with security debugging tools rather than judging one rule in isolation.
Do Data Policies run for imported or integrated data?
Data Policies are intended to enforce data requirements beyond the standard form, including data brought in through mechanisms such as imports and web services. Test the actual integration path and policy configuration before release.
Official references and next step
Review the current ServiceNow Access Control documentation and ServiceNow Data Policy documentation. Product behavior can change between releases, so confirm against the documentation for your instance family.