Ui policy vs Data policy??

[ZebaT]

Hi all,

Ui policies are for client side and Data policy for Server side I understand this.

I see option to convert ui policy to data policy, wanted to understand requirement or usecase for this.

Also data policy has check box to act as UI policy so I not able to understand then why UI policy will be required if data policy when checked as UI policy serves same purpose.

It's confusing can any one give practical usecase for all scenario and differentiate it. 

Thanks

[Rafael Batistot · Accepted solution]

Hi @ZebaT 

This post might help you to understand 

https://www.servicenow.com/community/servicenow-ai-platform-articles/difference-between-data-policy-...

[Nikhil Bajaj9 · Accepted solution]

Hi @ZebaT ,

Let me try to explain in a very simple language. 

UI Policy will work when data is entered through Form (Client side/Catalog/ Front end). For an example you made Phone numebr filed as mandatory from the form. It will make sure that phone number is not blank. But

It will not work when data is entering into the system by Import Sets(Transform Map) or integrations. User will be able to enter/upload blank phone numbers while importing data. If you want phine number field restriction to be applied on backend data ( Import set/ integration) as well then you should use data policy. Data policy will also make sure that blank phone numbers are not entering into the system.

So UI policy is stopping blank phone numbers from Form/catalog/ front end while Data policy is stopping blank phone numbers from backend data entry (Import set/integration). The purpose of both are same but the place they are working are different.

So when you have created a Data policy (to restrict any field value from backend) you can also check the checkbox to use it as UI policy to restrict the same field value from frontend. So in this way you are making sure that data will eb consistent does not matter entring from Front end or back end.

Hope it will clear the air.

[Aditya_hublikar · Accepted solution]

Hello @ZebaT ,

I have outlined some differences between UI Policy and Data Policy below.

UI Policy

1. UI Policy is client-side and is used for configuration such as Read-only, Mandatory, and Visible fields.

2. We can write scripts in UI Policies for additional modifications.

3. UI Policies are applied only on UI forms.

4. UI Policies do not apply to onCellEdit actions (List view editing).

5. To convert a UI Policy to a Data Policy, the following conditions must be met:
   i) Global checkbox should be checked
   ii) There should be no visibility actions
   iii) Run scripts checkbox should be unchecked

Data Policy

1. In Data Policy, there are only options for Read-only and Mandatory.

2. Data Policies run on the server side, meaning they are enforced when data is inserted or updated in the database (table).

3. There is no option to write scripts in Data Policies.

4. Data Policies are applied even when data is inserted through Import Sets, Mobile UI, Web Services (API), or integrations.

5. For data policy to ui policy conversion there is no any pre-requisit.

(Note - to disble data policy during modifying/creating record using script like gliderecord we need set gr.setUseEngine(false))

If this helps you then mark it as helpful accept as solution.

Regards,

Aditya,

Technical Consultant

[Siddhesh Gawade · Accepted solution]

@ZebaT ,

I will give you a short answer.

• UI Policy: Applies only to the UI, it can show/hide fields, clear values, or make a field required in forms, but it does not enforce rules on the database/backend.

• Data Policy: Enforces validation on the server/database level and prevents blank or invalid values from entering the system via imports or integrations.

• Best practice: Use a Data Policy as the authoritative backend validation. If you want the same behavior in the UI, enable the Data Policy’s “use as UI policy” option (so you don’t have to recreate the UI rule). If validation is needed only in the front end, use a UI Policy alone.

Regards,
Siddhesh Gawade

[Utpal Dutta · Accepted solution]

Hi @ZebaT ,

I hope you're doing well. I see that people have already provided you many links but I'll give you a simple use case on which I worked,

UI policy: Let's say you want to make "Assigned to" mandatory when "Assignment group" is changed. Now this will work fine when it's an interactive session meaning when a user is changing Assignment group on Incident form.

Data policies: Lets say above scenario is non interactive meaning Incident is getting created from an inbound integration. At this time if you have UI policy & Data policy then integration will fail & return error.

Now lets say you don't want to stop an integration from inserting record in incident table if "Assigned to" is not there because Assignment group manager can assign that incident later. So you will only create UI policy but not data policy.

I hope my answer helps, if it does then please mark it "Helpful" & "Accept the solution".

Thanks

[Ankur Bawiskar · Accepted solution]

@ZebaT 

Thank you for marking my response as helpful.

As per new community feature you can mark multiple responses as correct.

💡 If my response helped, please mark it as correct ✅ as well so that this helps future readers find the solution faster! 🙏

[VaishnaviK3009]

1. UI Policies are client-side and control how fields behave on the form (mandatory, read-only, hide). They work only in the UI.
2. Data Policies are server-side and ensure data rules are enforced from all sources (UI, imports, APIs, scripts).
3. The option to convert UI Policy to Data Policy is used when a rule created only for the UI must also be enforced on the server to prevent bad data from non-UI sources.
4. The “Use as UI Policy” checkbox in Data Policy allows one rule to work both on the UI and server, but it supports only mandatory and read-only actions. Since Data Policies cannot hide fields or handle complex UI logic, UI Policies are still required.

In short:
UI Policy = UI behavior
Data Policy = data integrity

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for.

Thank You

[Aditya_hublikar · Accepted solution]

Hello @ZebaT ,

I have outlined some differences between UI Policy and Data Policy below.

UI Policy

1. UI Policy is client-side and is used for configuration such as Read-only, Mandatory, and Visible fields.

2. We can write scripts in UI Policies for additional modifications.

3. UI Policies are applied only on UI forms.

4. UI Policies do not apply to onCellEdit actions (List view editing).

5. To convert a UI Policy to a Data Policy, the following conditions must be met:
   i) Global checkbox should be checked
   ii) There should be no visibility actions
   iii) Run scripts checkbox should be unchecked

Data Policy

1. In Data Policy, there are only options for Read-only and Mandatory.

2. Data Policies run on the server side, meaning they are enforced when data is inserted or updated in the database (table).

3. There is no option to write scripts in Data Policies.

4. Data Policies are applied even when data is inserted through Import Sets, Mobile UI, Web Services (API), or integrations.

5. For data policy to ui policy conversion there is no any pre-requisit.

(Note - to disble data policy during modifying/creating record using script like gliderecord we need set gr.setUseEngine(false))

If this helps you then mark it as helpful accept as solution.

Regards,

Aditya,

Technical Consultant

[Aditya_hublikar]

What Data Policy (Use as UI Policy) cannot do

• Cannot control field visibility (show / hide fields)

• Cannot run scripts

• Cannot handle complex conditions or dynamic logic

• Limited to mandatory and read-only only

[Siddhesh Gawade · Accepted solution]

@ZebaT ,

I will give you a short answer.

• UI Policy: Applies only to the UI, it can show/hide fields, clear values, or make a field required in forms, but it does not enforce rules on the database/backend.

• Data Policy: Enforces validation on the server/database level and prevents blank or invalid values from entering the system via imports or integrations.

• Best practice: Use a Data Policy as the authoritative backend validation. If you want the same behavior in the UI, enable the Data Policy’s “use as UI policy” option (so you don’t have to recreate the UI rule). If validation is needed only in the front end, use a UI Policy alone.

Regards,
Siddhesh Gawade