UI Policies and Data Policies both change field behavior, but they answer different enforcement questions. In the ServiceNow CAD workflow, UI Policies execute on the client and can make fields mandatory, read-only, or visible based on form state. Data Policies execute server-side and can enforce mandatory or read-only behavior regardless of whether a record is updated through a form, import, API, or another server-side path.
The distinction follows the same trust boundary as RBAC and other access controls: interface behavior is not the same as data enforcement. A hidden or mandatory field on one form does not guarantee the data remains protected when a different interface writes the record.
The reusable mental model is simple: use a UI Policy when the primary goal is interactive form behavior; use a Data Policy when the rule must survive every record-update path. Use both only when the same business requirement genuinely needs immediate UI guidance and durable server-side enforcement.
UI Policies shape the browser experience
A UI Policy can react to field values and change mandatory, read-only, or visible attributes without requiring custom client code.
It is a strong first choice when the requirement is declarative form behavior.
Because it is client-side, test the exact form or workspace experience where the policy should run; another interface may not share the same client behavior.
UI Policy behavior should be tested in the exact user experience where it is meant to help. Different form technologies, workspaces, catalog experiences, and custom interfaces may not execute the same client policy in the same way. A UI requirement that is critical for one fulfillment process may need a different presentation mechanism elsewhere. Treat UI Policy scope as part of the experience contract rather than assuming one client configuration automatically governs every interface that can display the table.
Data Policies protect the stored record
A Data Policy runs server-side and is not dependent on the browser form.
That makes it appropriate for mandatory/read-only requirements that must apply to imports, APIs, list edits, flows, and other non-form updates.
A Data Policy cannot simply replace every UI Policy because visibility is a user-interface concern and advanced client behavior may require a UI Policy script or Client Script.
Data Policies deserve special attention when integrations are introduced. An API client that previously inserted partial records can begin failing once a field becomes mandatory server-side. That may be the correct outcome, but integration owners need notice, error handling, and migration time. Server enforcement is powerful because it closes bypass paths; it also creates a stronger data contract that every producer must satisfy. Roll out new Data Policies with impact analysis rather than treating them as isolated form changes.
The same field can need two kinds of control
A field might need to become mandatory immediately when a user selects a category and also remain mandatory when an integration writes the record.
A UI Policy can provide the immediate visual cue; a Data Policy can enforce the stored-data requirement.
If both are used, keep the condition semantics aligned so users do not see one rule while the server enforces another.
When both policy types represent the same business requirement, use shared naming and documentation so future maintainers know they are paired intentionally. If the client condition later changes and the Data Policy does not, users can be told a field is optional only to receive a server rejection on submit. A simple regression test covering the true and false conditions on both form and server paths can detect this drift before production.
Use as UI Policy changes the execution footprint
ServiceNow can configure a Data Policy to behave on the client as well as server-side.
That can reduce duplicate configuration for simple mandatory/read-only rules.
Test carefully when the application needs visibility changes, advanced scripts, or form-specific behavior because those requirements may still belong to a dedicated UI Policy.
Use-as-UI-Policy behavior can be attractive because it reduces duplication, but it should not make developers forget the difference between presentation and persistence. A server rule promoted to the client may still need different wording, field visibility, or interaction timing than a dedicated UX policy. Favor one combined policy when the semantics truly match; separate them when the user experience needs richer behavior than the storage rule can express cleanly.
Policies are not substitutes for ACL security
Mandatory, read-only, and visible attributes shape data entry; they do not replace record or field authorization.
Use application security controls and Access Controls when the requirement is that a user must not read or change data at all.
A field that is merely hidden by client logic can still be accessible through another interface if security policy allows it.
Read-only presentation is particularly easy to confuse with authorization. A field shown as read-only in the browser can still be writable through an API, import, background script, or another UI unless ACLs or server validation prevent it. Use UI Policies to communicate and guide, Data Policies for certain data-state constraints, and ACLs for who may access the field. Clear separation of those responsibilities makes security debugging much more predictable.
Imports and integrations reveal the real boundary
Test a policy through import sets, APIs, background scripts, and flows when those are supported business paths.
If the rule must apply there, server-side enforcement is required.
This is where many UI-only designs fail: the form looks correct while imported records violate the business requirement because the client never participated.
Testing alternate update paths should include bulk imports and flows that run under privileged identities. Those processes may intentionally bypass user-facing requirements or may accidentally create invalid data because the original developer never considered them. Identify which producers are allowed to supply defaults, which must meet the same mandatory state as users, and whether any maintenance script requires a controlled exception. The policy should be designed around the authoritative record, not around the most common form.
Order and conflicting policy can create counterintuitive behavior
Multiple UI Policies or scripts can affect the same field, and their order and reverse behavior influence the final form state.
Multiple server rules can similarly impose overlapping constraints.
Avoid several policies fighting over the same attribute; centralize the business condition where possible and document which rule has authority when conditions overlap.
Conflicting policies are often a symptom of unclear ownership. One team may make a field read-only after approval while another policy makes it editable for a specific category. Instead of adding more orders until the screen looks right, write the business precedence first: which state should win and under what condition? Then implement the minimum policy set that expresses that precedence. Declarative configuration is maintainable only when the underlying rule is unambiguous.
A practical incident scenario exposes the difference
Suppose an incident category requires a business justification before closure.
A UI Policy can make Justification mandatory as soon as State becomes Closed, helping the fulfiller understand what is required.
A Data Policy or equivalent server-side rule ensures an integration cannot close the incident without the same required value. The UI helps; the server protects consistency.
In the incident example, also test the transition away from Closed. If the justification was mandatory only for closure, should it remain mandatory when the incident is reopened? UI Policies can reverse field attributes based on condition changes, while server-side requirements need equivalent lifecycle reasoning. State transitions in both directions expose policy assumptions that are easy to miss when testing only the happy path toward completion.
Choose policy from enforcement scope
Ask whether the rule is about what the user should see now or what the database must accept from every path.
Use the narrowest mechanism that guarantees the requirement and do not confuse form behavior with authorization.
That distinction is consistent with broader data-quality accountability: quality controls are effective only when they operate on every path that can change the authoritative data.
A policy review should include observability. Track integration failures or import errors caused by mandatory/read-only enforcement and collect user reports when forms behave unexpectedly. A sudden increase after deployment can indicate that the policy reached an update path the designers did not know existed. That feedback is valuable architecture evidence: it reveals hidden producers and helps the team decide whether the policy, the producer, or the data model should change.
Policy changes should be released with producer inventory. List forms, workspaces, imports, APIs, flows, integration users, and background jobs that write the affected table. For a new Data Policy, run representative updates from each important producer before production. That turns the server-side guarantee into a deliberate contract instead of a surprise discovered when a scheduled integration begins rejecting records overnight.
UI Policies should also be reviewed for accessibility and clarity. Making a field read-only or hidden can confuse users if the reason is not visible and if another field depends on it. Where the business process is complex, pair dynamic behavior with concise messages or help text so the form explains what changed. Good client policy reduces cognitive load rather than merely preventing input.
A final policy review should include documentation of the authoritative layer. Mark which requirements are UX-only, which are server data constraints, and which are true access-control rules. That simple map prevents future developers from trying to solve a security problem with a UI Policy or from adding a server-side constraint where only form guidance was intended. Clear ownership of the rule reduces duplicated configuration and makes later debugging much faster.
