Field security and data policies
Quick answer
Control who reads and writes individual fields, and enforce rules that apply to imports as well as forms.
Key takeaways
- Field ACLs are table.field, wildcards catch the rest
- Data policies enforce on every write, UI policies only in the browser
- Use the debugger to find the deciding rule
- New fields inherit wildcards, so review after each release
Field ACLs
A field ACL controls read or write on one column, written as table.field. A wildcard such as incident.* covers every field not explicitly listed. When users can see something they should not, a permissive wildcard is usually the reason.
Data policies versus UI policies
A UI policy runs in the browser and can be bypassed by an import or an API call. A data policy runs on the server for every write, including imports and web services. Anything that must always be true belongs in a data policy.
Working practices
Field security is where instances quietly drift.
- Document why each restrictive ACL exists, in its description
- Use the security debugger rather than guessing which rule applied
- Convert critical UI policies to data policies for integration safety
- Review field ACLs after each release, new fields inherit the wildcard
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which enforces mandatory on an import?
- A. UI policy
- B. Data policy
- C. Client script
- D. Form layout
Show answer
B. Data policy
Data policies apply to every server side write.
What often causes unintended field visibility?
- A. A missing index
- B. A permissive wildcard field ACL
- C. A UI policy
- D. A related list
Show answer
B. A permissive wildcard field ACL
Wildcard ACLs grant access to fields you never explicitly restricted.