Exam objective 2.4 asks you to create and apply UI policies, data policies, and client scripts. Before you can pass the SNOW-CSA exam, you need to understand how ServiceNow controls what users see (the interface) and what data they can submit (the rules). This chapter strips away the jargon so you can master these two essential guardrails.
Jump to a section
A simple way to picture User Interface Policies and Data Policies
Have you ever tried to book a flight and hotel together, only to have the website shout at you for making a mistake? That's exactly what User Interface and Data Policies do.
Imagine you're booking a holiday for two people. The booking site has a form. First, it asks for your names. When you type 'Sarah' in the 'First Name' field, the site immediately greys out the 'Title' dropdown so you can only choose 'Ms.' or 'Mrs.' – that's a UI Policy reacting instantly to your input, controlling what you see and can click.
Later, you enter passport numbers. But if one person's passport number is missing a digit, the site won't let you click 'Pay Now'. Instead, it highlights the field in red and a message says, 'Passport number must be 9 characters.' That's a Data Policy preventing bad data from being saved to the database.
Finally, you try to book a double room for three people. The system flatly refuses: 'Maximum 2 guests per double room.' This is a Data Policy enforcing a business rule – the database itself will reject that record.
In short, UI Policies control what you see and can do on the screen (like a store manager rearranging shelves). Data Policies control what data is allowed to be saved (like a bouncer checking IDs at the door).
In ServiceNow, you will build forms and records for many things: incident reports, change requests, hardware assets, and more. But giving users an empty form is like giving them a blank cheque. They could type anything, break the data, or create chaos. That is why we have two types of guardrails: User Interface (UI) Policies and Data Policies. They work together but at different levels.
A User Interface Policy controls what happens on the screen while the user is filling out a form. It runs in the user's web browser without waiting for the server. Think of it as the form's 'live assistant'. When a user checks a box or selects a value from a dropdown, a UI Policy can instantly show or hide fields, make them read-only, or populate them with a default value. For example, if a user selects 'Hardware' as the asset type, a UI Policy can instantly show a hidden field called 'Serial Number' and make the 'Operating System' field mandatory. This happens immediately, without needing to save the form first.
There are two main parts to a UI Policy. The first is the Condition: a set of rules that must be true for the policy to activate. For example, 'Category equals Software'. The second part is the Actions: what happens when the condition is met. You can set fields to visible, invisible, mandatory, or read-only. You can also choose whether the policy applies just once (on load) or every time the condition changes (on change).
The second concept is a Data Policy. While a UI Policy controls the user's experience at the screen, a Data Policy controls the rules for the database itself. A Data Policy is enforced on the server side, meaning it runs when a record is being saved or updated. It does not care what the user sees on the screen. A Data Policy can force a field to be mandatory or read-only, and it can prevent a record from being saved if the rules are broken. Unlike UI Policies, Data Policies also apply when data is imported via web services or other automated methods. This makes them the 'last line of defence' for data quality.
Why does ServiceNow have both? Because they solve different problems. UI Policies improve the user experience by only showing relevant fields, reducing confusion. Data Policies ensure data integrity, no matter how the data enters the system. For example, you might have a UI Policy that hides the 'Software License Key' field unless the user selects a specific software product. But you also need a Data Policy that makes the 'License Key' field mandatory, so even if someone tries to import data via an API (bypassing the form entirely), the database will reject the record if the license key is missing.
When you create these policies in ServiceNow, you find them under 'System Policy' in the left-hand menu. Both types of policies have a table that they apply to (like the 'Incident' table) and a set of conditions. For UI Policies, the conditions can check the value of specific fields on the form. For Data Policies, the conditions check the state of the data being saved. Importantly, a Data Policy can override a UI Policy. If a Data Policy makes a field mandatory, the UI Policy cannot make it optional on the screen.
A common beginner mistake is to think a UI Policy is enough for data protection. It is not. A user could open the same form via a REST API or a mobile app that ignores your UI Policy. Only a Data Policy can enforce rules across every entry point.
Finally, you can also use a Client Script to do things that UI Policies cannot, like complex calculations or sending data to another system when a value changes. But UI Policies are simpler, require no coding, and are the preferred method for basic field visibility and mandate. ServiceNow recommends using UI Policies first, and only falling back to Client Scripts when you need more advanced logic.
Identify the Table
Decide which table (e.g., Incident, Request, Change Request) needs the policy. Policies are scoped to a specific table, so you must know your data model.
Define the Condition
Write a condition that triggers the policy. For example, 'Category equals Hardware'. This condition uses an 'equals' operator and a specific value. The policy will only act when this condition is true.
Set UI Policy Actions (if using UI Policy)
Choose what happens to fields when the condition is met: Visible, Invisible, Mandatory, Read-Only. You can set multiple actions for different fields. Also select whether the policy runs On Load only or On Change.
Set Data Policy Actions (if using Data Policy)
Choose which fields become Mandatory or Read-Only at the database level. There is no visibility option here. You can also toggle 'Enforce on Load' to apply the rule immediately on form load.
Test the Policy
Open a record in the relevant table. For UI Policies, check that fields appear/disappear as expected when you change the triggering field. For Data Policies, try to save a record that violates the rule and confirm the error message appears.
Consider Edge Cases
Think about non-form entry points: web services, import sets, mobile apps. If those channels must obey the rule, ensure you have a Data Policy, not just a UI Policy. Also verify that no conflicting policies (like a global policy) override your new rule.
Imagine you work as a ServiceNow administrator for a medium-sized company called 'NorthStar IT'. The company uses ServiceNow to track all employee requests for hardware and software. Your manager asks you to improve the request form so that employees only see fields relevant to their request, and that no incomplete request can ever be saved.
Step 1: You open the 'Request' table in ServiceNow and create two User Interface Policies. The first UI Policy is called 'Hardware Request Visibility'. The condition is: 'Category equals Hardware'. The actions are: show the field 'Model Number' and hide the field 'Software Name'. You also set 'Serial Number' as mandatory, but only on the screen. The second UI Policy is called 'Software Request Visibility'. Its condition is: 'Category equals Software'. Its actions hide the 'Model Number' field and show the 'Software Name' field. Now, when an employee selects 'Hardware' from the category dropdown, the form instantly changes. They see the hardware fields and cannot see the software fields, reducing confusion.
Step 2: Your manager is still worried about bad data. What if someone uses an API to submit a request directly? The UI Policy would not run because there is no form. You create a Data Policy next. You open 'Data Policies' and create one for the Request table. The action: make 'Model Number' mandatory and 'Serial Number' mandatory. This rule is enforced on the server. Now, if any system attempts to save a request for hardware without a model number, it will fail. The database itself rejects the record.
Step 3: You test the Data Policy by trying to create a hardware request manually. You leave 'Model Number' blank. You expect the form to submit, but it does not. Instead, you see an error message at the top of the form. That is the Data Policy blocking the save. You also test by using a REST API tool to submit a new record with a missing model number. The API returns a 400 error. The Data Policy protected your database.
Step 4: You also create a third policy to handle a business rule: 'If Request Type is Urgent, then the field 'Approval Required' must be set to 'Yes' and cannot be changed by the user.' You create a UI Policy that makes 'Approval Required' read-only when 'Urgency' equals '1 - High'. But you also create a Data Policy that makes 'Approval Required' read-only at the database level for urgent requests. This double-layer ensures that no one, not even a manager bypassing the form, can change that field.
This is the daily work of a ServiceNow administrator. You constantly balance user experience (only showing what they need) with data integrity (ensuring the data is complete and correct). You use UI Policies for the form, and Data Policies for the entire system.
The SNOW-CSA exam will test your ability to distinguish between UI Policies and Data Policies, and to understand when to use each. The exam questions are often scenario-based: they describe a situation and ask which tool you should use. The trap is that both policies can make a field mandatory, but they do it at different levels. Memorise this: 'UI Policy controls the screen. Data Policy controls the database.'
Here are the exact exam topics to focus on:
The 'Conditions' tab in both policies. You must understand that a condition uses the format 'Field Operator Value' (e.g., 'Category is Hardware'). The exam may ask you to identify a valid condition.
The 'Actions' tab in UI Policies. You need to know that you can set fields to Visible, Invisible, Mandatory, or Read-Only. The exam might show you a scenario where a field should be hidden when another field is empty, and ask you what action to choose.
The difference between 'On Load' and 'On Change' reverse for UI Policies. 'On Load' runs only when the form first opens. 'On Change' runs every time the condition changes. The exam will test this: if you want a field to hide when a dropdown is changed, you use 'On Change'.
The 'Global' and 'Table' scopes. You can create a UI Policy that applies to all tables (Global) or just one table. The exam will ask you where to apply a policy for a specific form.
Data Policy vs. UI Policy precedence. Data Policies always take priority during a save operation. A common exam question: 'You set a field to mandatory via a UI Policy, but set it to optional via a Data Policy. What happens?' The answer: the Data Policy wins, and the field is optional (though the UI Policy will still show it as mandatory on the screen until you try to save).
The 'Enforce on Load' checkbox in Data Policies. If unchecked, the policy only runs on submit. If checked, it also runs when the form loads, potentially making fields mandatory immediately. The exam loves this nuance.
Trap patterns to watch for:
The exam might describe a scenario where data is being imported via an external tool. The correct answer will always be 'Data Policy' because UI Policies only run in the browser.
The exam might describe a requirement to show or hide fields based on a user's role. ServiceNow uses another tool called 'ACL' (Access Control) for that. UI Policies and Data Policies do not control permissions by role – they control based on field values.
The exam might describe a requirement to perform a complex calculation or call an external API when a field changes. That is a Client Script, not a UI Policy. UI Policies are simple rules; client scripts are JavaScript.
Some questions will show you a screenshot of the UI Policy form and ask you to identify the mistake. Common mistakes: forgetting to check the 'Active' checkbox, setting a condition incorrectly, or confusing 'Visible' with 'Mandatory'.
Finally, memorise these key definitions:
UI Policy: A no-code rule that runs in the browser to control field visibility, mandate, and read-only state based on field values.
Data Policy: A server-side rule that enforces field mandate and read-only state on any action that writes to the database.
Client Script: A JavaScript code that runs in the browser for more advanced logic.
Condition: A logical statement that must be true for the policy to activate (e.g., 'State is equal to new').
UI Policies run in the user's browser and control which fields are visible, mandatory, or read-only based on field values.
Data Policies run on the server and enforce field mandate and read-only state on every save attempt, including via APIs and imports.
If you need a rule to apply when data comes from an external system, always use a Data Policy, not a UI Policy.
UI Policies can be set to run 'On Load' (once when the form opens) or 'On Change' (every time the condition changes).
Data Policies always override UI Policies during a save operation, meaning the database rule wins.
Always use a UI Policy first for basic field visibility and mandate; only use Client Scripts when you need complex logic like calculations or API calls.
A condition in a policy is structured as 'Field Operator Value', for example 'State equals New'.
Data Policies have an 'Enforce on Load' toggle that, when checked, applies the rule as soon as the form opens rather than only on submit.
These come up on the exam all the time. Here's how to tell them apart.
UI Policy
Runs in the user's browser (client-side)
Controls only what is visible, mandatory, or read-only on the form
Is bypassed by APIs, import sets, and other automated data entry methods
Data Policy
Runs on the server (server-side)
Controls what data can be saved to the database
Applies to all data entry methods, including APIs and imports
UI Policy
Requires no coding; configured through user interface
Can only show, hide, set mandatory, or set read-only on fields
Best for simple, static rules based on field values
Client Script
Requires JavaScript coding
Can perform complex calculations, API calls, and manipulate fields in advanced ways
Best for dynamic, logic-heavy behaviour
Data Policy
Controls field mandatory and read-only states based on field values
Focuses on data integrity
Cannot grant or deny read/write permissions to specific roles or users
Access Control (ACL)
Controls who can read, write, create, or delete records based on user roles and conditions
Focuses on data security and permissions
Cannot make a field mandatory or read-only based on another field's value
UI Policy On Load
Runs only once when the form first opens
Good for setting initial field states based on existing record data
Does not react if the user later changes a field value
UI Policy On Change
Runs every time the condition's field value changes
Good for dynamic forms that adapt as the user fills them in
Can cause repeated actions if the user changes values multiple times
Mistake
UI Policies and Data Policies do the same thing, so you only need to create one of them.
Correct
UI Policies control the screen only; Data Policies control the database. You often need both to fully protect data and guide users.
Beginners see that both can make fields mandatory and assume they are redundant, not realising they operate at different layers.
Mistake
A UI Policy can prevent a user from saving a record with bad data because it can show error messages.
Correct
UI Policies cannot block a save. They only change the form appearance. Only a Data Policy (or a server-side script) can prevent a record from being saved.
The instant visual feedback a UI Policy gives (like greying out a field) feels like blocking the user, but the user could still submit the form via script or API.
Mistake
Data Policies are applied to forms, so they only run when someone interacts with a form in ServiceNow.
Correct
Data Policies run on the server for any database write operation, including web services, import sets, and scheduled jobs.
Newcomers think 'policy' means 'form rule' and forget that data enters through many channels, not just the user interface.
Mistake
You can use a UI Policy to make a field mandatory only for a specific user role.
Correct
UI Policies cannot check roles. They only check the values of fields on the form. For role-based rules, you need Access Controls (ACLs).
The word 'policy' sounds like a security mechanism, so people assume it can handle user permissions.
Mistake
If a UI Policy hides a field, the data in that field is deleted from the record when the user saves.
Correct
Hiding a field only hides it on the screen. The data remains in the database if it was already there. UI Policies do not delete data.
The visual effect is so strong that users think the data is gone, but it is just hidden from view.
Mistake
A Data Policy can make a field visible or invisible on the form.
Correct
Data Policies only control mandatory and read-only states at the database level. They do not control visibility on the form. That is the job of UI Policies.
The names are similar, so people confuse their capabilities. Data Policies are about 'what is allowed to be saved', not 'what is shown'.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A UI Policy controls what users see and can interact with on a form (visibility, mandatory, read-only). A Data Policy controls what data can be saved to the database, regardless of how it enters the system.
Yes, a UI Policy can make a field appear mandatory on the screen, but it cannot stop the record from being saved if the data comes from an API. A Data Policy makes the field truly mandatory at the database level: the save will fail if the field is empty, no matter how the data arrives.
Use a UI Policy for basic field controls (show/hide, mandatory/read-only) based on simple conditions. Use a Client Script when you need complex logic, such as calculations, concatenating field values, or making API calls before the form responds.
Yes, Data Policies apply to all database operations, including imports, web services, and scheduled jobs. UI Policies only apply when a user is interacting with a form in the browser.
During a save operation, the Data Policy takes priority. If the Data Policy says a field is mandatory, the UI Policy cannot make it optional for saving, though the UI Policy might still show it as optional on the screen until the user tries to save.
If 'Enforce on Load' is checked, the Data Policy's rules (like mandatory) are applied when the form first opens. If unchecked, the rules are only applied when the user tries to save the record.
You've finished User Interface Policies and Data Policies. Continue through the SNOW-CSA study guide to build a complete picture of the exam.
Done with this chapter?