ServiceNow Field security and data policies

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.

The concept to be clear about first is that an access control answers a question about one operation on one thing, and the platform asks that question at more than one level. A table ACL covers the record. A field ACL covers one field on it. Both are evaluated, and both have to pass.

That ordering is what confuses people. A user who cannot read the table will not read the field however permissive the field rule is, because the table rule already said no. So a field ACL loosens nothing on its own; it can only restrict further within what the table already allows.

The other half is how a rule passes. An ACL has three parts: the roles it requires, a condition on the record, and an optional script. All three must be satisfied. A rule that requires a role, has a condition and a script that returns false will never grant anything, and reading only the roles field is how somebody concludes the platform is broken.

Where they live: sys_security_acl, with the name written as table.field, and the wildcard form table.* covering every field that has no rule of its own.

Evaluation order is the other thing worth holding in your head, because it explains behaviour that otherwise looks arbitrary. The platform looks for the most specific matching rule first: a rule on table.field, then the wildcard on that table, then the same pair on the parent table, and so on up the hierarchy. The first match that grants access ends the search for that level.

The practical consequence is that adding a rule on a child table can change behaviour that people believed came from the parent, and that a permissive wildcard on a table quietly grants every field with no rule of its own. Both are worth checking when access appears where it should not be.

Half an hour, and it is the test that separates a field that is hidden from a field that is secured.

1. Pick a field that should be restricted. Create a read ACL on it requiring a role, and grant that role to nobody.
2. Impersonate an ordinary user and open the form. The field should not be visible.
3. Now open the same record in a list view and add the column. Still hidden.
4. Now query the record through the Table API as that user and read the JSON. This is the test that matters, and a UI policy would have failed it while an ACL passes it.
5. Export the list to a spreadsheet as that user and check the export too.
6. Finally, check a related list and a report that includes the field.

Steps four and five are where field level security is either real or discovered to be decorative. If the value appears in either, whatever is hiding it on the form is not a security control. See access controls.

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.

The distinction is worth stating as a rule, because the three mechanisms are constantly confused and only one of them is a security control.

UI policies run in the browser and change how the form behaves: mandatory, read only, visible. They are for usability. A user can bypass them entirely by using the API, so they secure nothing.

Data policies run on the server and enforce mandatory and read only regardless of how the record arrives, including through imports and the API. They are about data integrity: this field must have a value, whatever wrote it.

ACLs decide who may read or write at all. They are the security control.

So the question to ask about any requirement is which of three things it is: helping a user fill in a form, guaranteeing a field is populated, or preventing somebody from seeing a value. Each has exactly one right mechanism, and the common mistake is using the first for the third. See data policies and UI policies versus client scripts.

A fourth mechanism belongs in the same comparison because it gets used for the same requirements: dictionary attributes. Marking a field read only or mandatory in the dictionary applies everywhere and cannot be conditional, which makes it right for something that is always true and wrong for anything that depends on state. When a requirement has no conditions at all, the dictionary is the simplest place to express it and the easiest for the next person to find.

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

Three practices keep this maintainable in a real instance.

Prefer roles to conditions where you can. A rule that names a role is readable by anybody. A rule with a script that walks a reference chain is correct today and unmaintainable by whoever inherits it.

Debug with the security rules elevated privilege rather than by guessing. It shows which rule was evaluated and which one denied, which turns a half day of trial and error into a minute.

Test as a real user, not as an administrator. Administrators pass almost everything, so an administrator confirming that security works has confirmed nothing. Impersonation is the minimum, and checking the API path as well is what the previous section argued.

Version note: ACL evaluation order and the wildcard behaviour have been stable for a long time, and what has moved is the tooling around them, including the diagnostics and the newer permission constructs layered on top for scoped applications. The rules above hold; where a specific screen is named, confirm it exists on your release. See dictionary fields.

One more, about scale. Field level rules multiply quickly and every one is evaluated on every record in every list, so a table with forty field ACLs and a long list view does noticeably more work than one with four. Where a genuine requirement is to protect a group of fields together, it is usually better expressed as a smaller number of rules with a shared condition than as one rule per field, and it is far easier to review.

• Hiding a field with a UI policy and calling it secured. The API returns it.
• Testing as an administrator. Everything passes.
• Forgetting exports, reports and related lists. Three more places the value can appear.
• Scripts where a role would do. Correct now, unreadable later.

Writing an ACL takes ten minutes, and knowing which of the three mechanisms a requirement actually needs is the judgement the course builds.