UI policies let you control which fields users can edit based on form conditions — like making budget fields read-only after approval. You'll set up a condition and read-only action that enforces client-side restrictions without blocking server processes.
Why manual field control fails
Before UI policies, controlling field access meant either field-level ACLs (too rigid) or training users not to edit certain fields (doesn't work). Field administrators needed conditional read-only behavior — budgets editable during draft but locked after approval, assignment groups changeable by managers but not end users, dates that freeze when work begins. Manual enforcement created data integrity problems and frustrated users who couldn't tell which fields they should touch.
How UI policies control field access
A UI policy watches form conditions and applies actions when those conditions match. You define the 'when' (condition script or simple field checks) and the 'what' (read-only, mandatory, visible actions on specific fields). UI policies run client-side — they grey out fields and block user input, but server-side processes like Business Rules and integrations can still update those fields. This is different from ACL read-only, which blocks server updates too. Most policies start with simple conditions like 'State is Closed' and add field-specific read-only actions.
Beyond basic read-only policies
Production UI policies often combine read-only with visibility and mandatory actions to guide users through complex forms. You'll add role-based conditions so different user types see different field behaviors, table-specific policies for child tables, and global policies that apply across multiple forms. The sophisticated approach is building policy sets that work together — one policy handles state-based read-only, another handles role-based visibility, and they don't conflict with each other.
Before you start
- •ui_policy_admin role or admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Create the UI policy record
Navigate to System UI > UI Policies and click New. Set the Table field to your target table, give it a descriptive Name like 'Budget Read-Only After Approval', and leave Active checked. The Short Description should explain when this policy fires — it helps other admins understand your logic later.
Use naming that describes both the field and the trigger condition — you'll thank yourself when debugging multiple policies on the same form.
Configure the trigger condition
In the Conditions section, build the logic that determines when fields become read-only. For simple conditions, use the condition builder to set field checks like 'State is Approved'. For complex logic, check 'Advanced' and write a script that returns true when fields should be read-only. The condition runs every time the form changes, so keep it lightweight.
Test your condition with both true and false scenarios before adding actions — a broken condition means your read-only behavior won't trigger.
Set execution options
Check 'Reverse if false' so fields become editable again if the condition stops matching — this handles cases where users change the triggering field value. Leave 'On Load' checked so the policy applies when forms first open. Only uncheck 'On Load' if you want the policy to fire only after user interactions, which is rare.
Always enable 'Reverse if false' unless you want one-way read-only behavior that never unlocks.
Add UI policy actions
Save the policy, then scroll to the UI Policy Actions related list and click New. Set Field Name to the field you want to make read-only, check the 'Read Only' checkbox, and save the action. Add separate action records for each field you want to control — one action per field.
Don't combine multiple field actions into a single record — separate actions make it easier to modify individual field behavior later.
Test the policy behavior
Open a record that matches your table and modify the condition field to trigger the policy. The target field should grey out and become uneditable. Change the condition field back and verify the field becomes editable again. Test edge cases like loading records that already match the condition — the field should load as read-only.
Verify server-side updates work
Confirm that Business Rules and integrations can still update the read-only field even when the UI policy is active. Create a simple Business Rule or use a REST call to update the field while the UI policy condition is true. The update should succeed because UI policies only block client-side changes.
If you need to block server-side updates too, you want field-level ACLs instead of UI policies.
Best practices
Use specific conditions instead of broad ones — 'State is Closed' performs better than checking multiple state values or complex field combinations.
Never create UI policies that conflict with each other on the same field — the last policy to run wins, and execution order isn't guaranteed.
Test your policies with the actual roles that will use the forms — admin users often have permissions that bypass UI restrictions.
Keep condition scripts simple and avoid GlideRecord queries — UI policies run on every form interaction and slow conditions hurt user experience.
Document complex UI policies in the Short Description field — other admins need to understand your logic when they're debugging form behavior.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue