Understanding UI Policy and Catalog UI Policy Configurations, Conditions, and Execution Order in Rea

[BURLED]

Hi Everyone,

I am currently practicing Normal UI Policies and Catalog UI Policies in ServiceNow. I have understood the basic concepts, but I have a few questions regarding their configurations and how they work in real-time projects.

I would appreciate it if experienced ServiceNow Developers/Admins could clarify the following doubts.

1. UI Policy Configuration Options

In Normal UI Policies, we have options such as:

• Global

• Reverse if false

• Inherit

• On load

Could you please explain how each of these options works in real-time projects? When should we enable or disable them, and how do we decide based on business requirements?

2. UI Policy Actions and Conditions

• Can we configure multiple conditions and multiple UI Policy Actions within a single UI Policy?

• Is there any specific limit on the number of conditions or UI Policy Actions we can configure?

• How do we decide which conditions and actions are required for a particular business requirement?

3. Catalog UI Policies

I have some confusion regarding Catalog UI Policies.

When we open a Catalog UI Policy record and navigate to the Related Lists, we can see the UI Policy Actions section with a New button.

• When we click New, can we configure multiple conditions or actions for different catalog variables?

• Is there any specific limitation on the number of conditions or actions?

• How do Catalog UI Policies evaluate conditions and control catalog variables in real-time projects?

4. Order / Execution Sequence

In UI Policies and Catalog UI Policies, we have an Order or Sequence field.

For example:

• 100

• 200

• 300

How does this order work?

If we configure multiple UI Policies with different order values, will they execute based on the specified order?

Does the same execution order concept apply to both Normal UI Policies and Catalog UI Policies?

5. Identifying Conditions from Business Requirements

This is one of my main doubts.

In real-time projects, how do we identify which conditions should be configured in a UI Policy or Catalog UI Policy?

For example, when working on Incident, Problem, Change Request forms, or Service Catalog items, how do we identify the appropriate fields, conditions, and actions?

Does the Business Analyst or client provide these details through User Stories or Functional Specifications, or are developers expected to analyse the requirements and decide the appropriate conditions independently?

I would also like to understand how experienced developers identify these conditions when implementing new requirements.

I am trying to understand not just how to configure UI Policies technically, but also how these configurations are designed and implemented in real-time projects.

Any practical examples or real-time scenarios would be extremely helpful.

Thank you in advance for your valuable guidance!

Best regards,

Damodar.

[kmohammed · Accepted solution]

Hi Damodar — good questions, and they are all connected. Here is how these pieces work in real projects, in the order you asked.

1. The four configuration options (normal UI Policies)

- Global: when checked, the policy applies on every form view of the table. When unchecked, it applies only to the view you select. In real projects, check Global when the behavior must hold everywhere (for example, a field that must always be mandatory on an Incident), and leave it unchecked when the behavior is view-specific (for example, a field arrangement that only applies to one team's view).

- Reverse if false: when checked, the policy's actions are undone as soon as the condition stops being true. Example: Category = Network makes a field visible; change Category away from Network and the field hides again. Leave this checked for most show/hide and mandatory/optional behavior. Uncheck it only when the action should stick once triggered — for example, setting a default value that the user may then change freely.

- Inherit: when checked, the policy also applies to tables that extend the policy's table. Example: a policy on Task with Inherit applies to Incident, Problem, and Change, because they extend Task. Check it when the rule is genuinely common to the whole table family; leave it unchecked when the rule belongs to one table only, otherwise you will get surprising behavior on child tables.

- On load: when checked, the policy is evaluated when the form first opens, using the record's saved values. Leave this checked in almost all cases — without it, the form will not reflect the record's current state until the user changes a condition field, so a reopened record can show the wrong fields as mandatory or visible.

2. Multiple conditions and actions in one policy

Yes. One UI Policy has one condition set, and that set can contain multiple conditions combined with AND / OR. One UI Policy can also have many UI Policy Actions — each action targets one field and sets one behavior (mandatory, visible, or read-only, for example). There is no documented hard limit on the number of conditions or actions, but that is not a reason to pile everything into one policy. The practical rule is: one policy = one business rule. Example: "If Category is Network, show the Network field and make it mandatory" is one policy with one condition and two actions. If you add unrelated behaviors to the same policy, it becomes hard to debug when something stops working.

3. Catalog UI Policies

The same structure applies, but to catalog variables instead of table fields, and they run on the catalog request form (Service Portal), not on the platform form. When you click New in the UI Policy Actions related list of a Catalog UI Policy, each new action targets one catalog variable — so to control several variables, you add several action rows in the same policy. Conditions likewise reference the catalog item's variables. Evaluation is the same idea: when a variable's value changes (or the form loads, if On load is set), the condition is re-evaluated and the actions are applied or reversed. One key difference to remember: a normal UI Policy does not control catalog variables, and a Catalog UI Policy does not control platform form fields — use each one in its own context.

4. Order / execution sequence

Yes, the Order field controls the sequence, and it works the same way for normal and Catalog UI Policies: policies run in ascending Order (100 before 200 before 300), both on form load and whenever a condition field changes. This matters when two policies touch the same field — the later policy wins on that field. So use Order deliberately (leave gaps like 100, 200, 300 so you can insert a policy later), and avoid having two policies fight over the same field; if they must overlap, the higher-order policy should be the one whose behavior you want to prevail.

5. Identifying conditions from business requirements

In real projects, the conditions almost always come from the user story or functional specification — the Business Analyst or client states the rule in words, and the developer translates it. The translation pattern is: "When <field/variable> is <value>, then <field/variable> should be <mandatory / visible / read-only>." The "when" part becomes the condition, and the "then" part becomes the actions. Example from Incident: "When Category is Software, the Software version field must be shown and mandatory" — condition: Category is Software; actions: Software version is visible and mandatory. If a story does not state the rule that precisely, ask for it before building — guessing the condition is how UI Policies end up conflicting with each other.

One final caution that matters in real projects: UI Policies are client-side form behavior only. They do not enforce security — a field made read-only or hidden by a UI Policy can still be changed through an API, import, or background script. If a rule must truly be enforced, back it with an ACL or a data policy as well.

Regards,

Karimuddin

[Tarun Rekandar · Accepted solution]

Hi @BURLED,

Here is a simple real-time scenario that covers your questions.

Scenario: Network Incident and New Laptop Request

Incident form (Normal UI Policy)

1. Requirement: When Category = Network, the agent must fill in Affected Location and Impact Scope.
2. Condition: Category is Network
3. Actions (two in one policy): Affected Location is Visible and Mandatory, and Impact Scope is Visible and Mandatory.
4. Options used:

• On load: checked, so existing Network incidents show the fields when opened.
• Reverse if false: checked, so if the agent changes Category to Software, the fields hide and are no longer mandatory.
• Global: checked, so it applies to all views.
• Inherit: unchecked, since the fields exist only on Incident.

Laptop Request (Catalog UI Policies)

• Policy A: When Employee Type = Contractor, Contract End Date is Visible and Mandatory. For anyone else it stays hidden.
• Policy B: When Need Accessories = Yes, Accessory Type is Visible and Mandatory. If the user switches back to No, the field hides and its value is cleared (Clear value checked).
• Each variable gets its own action, added through New on the UI Policy Actions related list.

Order example

• Order 100: hide Accessory Type by default.
• Order 200: show Accessory Type when Need Accessories = Yes.
• Lower order runs first, so 200 overrides 100 and the field shows correctly.

How the requirement becomes a configuration
The BA writes: “When Category = Network, Location is mandatory.”

• “When” becomes the condition (Category is Network).
• “Then” becomes the actions (Location visible and mandatory).
• “Otherwise” tells you to check Reverse if false.

Accept the solution if it assisted you with your question & Mark this response as Helpful.

Regards,

Tarun

[Aditya_hublikar · Accepted solution]

Hello @BURLED ,

Here are my suggestions based on practical ServiceNow development:

1. UI Policy Configuration Options:

• Global: Makes the UI Policy applicable across different views.if not then need to specify specific view on which we have to apply ui policy .

• Reverse if false: Reverses the configured actions when the conditions become false.

• Inherit: Allows the policy to apply to extended tables.

• On load: Evaluates the policy when the form loads.

2. UI Policy Conditions and Actions:

• Yes, you can configure multiple conditions and multiple UI Policy Actions within a single UI Policy.

• Conditions can be combined using AND/OR operators.

• There is no commonly prescribed fixed limit; keep configurations simple and manageable.

• For example, if Priority is Critical, make Assignment Group mandatory and display additional fields.

3. Catalog UI Policies:

• You can configure multiple conditions using catalog variables.

• You can create multiple UI Policy Actions for different variables.

• Actions can control variable visibility, mandatory, and read-only properties.

• They are evaluated when the catalog item loads and when variable values change.

4. Order / Execution Sequence:

• UI Policies generally execute according to their configured order.

• A lower order value executes before a higher value (100 before 200).

• This applies to both Normal UI Policies and Catalog UI Policies.

• Be careful when multiple policies control the same field, as their actions may conflict.

5. Identifying Conditions from Business Requirements:

• Usually, the Business Analyst or client provides requirements through User Stories, Acceptance Criteria, or Functional Requirement Documents.

• Developers analyse these requirements and identify the appropriate fields, conditions, and actions.

• For example, if the requirement says Resolution Notes should be mandatory when an Incident is Resolved, the condition will be State = Resolved and the action will be Mandatory = True.

6. Practical Approach:

• Understand the business requirement first.

• Identify the table, fields, or catalog variables involved.

• Decide the appropriate conditions and actions.

• Configure the UI Policy and test both true and false scenarios.

• Check whether other UI Policies or Client Scripts are affecting the same fields.

My suggestion: Don't just memorise the configuration options. Try implementing different business scenarios in your PDI. That will help you understand when and why to use each option in real-time projects.

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

Regards,

Aditya

[kmohammed · Accepted solution]

Hi Damodar — good questions, and they are all connected. Here is how these pieces work in real projects, in the order you asked.

1. The four configuration options (normal UI Policies)

- Global: when checked, the policy applies on every form view of the table. When unchecked, it applies only to the view you select. In real projects, check Global when the behavior must hold everywhere (for example, a field that must always be mandatory on an Incident), and leave it unchecked when the behavior is view-specific (for example, a field arrangement that only applies to one team's view).

- Reverse if false: when checked, the policy's actions are undone as soon as the condition stops being true. Example: Category = Network makes a field visible; change Category away from Network and the field hides again. Leave this checked for most show/hide and mandatory/optional behavior. Uncheck it only when the action should stick once triggered — for example, setting a default value that the user may then change freely.

- Inherit: when checked, the policy also applies to tables that extend the policy's table. Example: a policy on Task with Inherit applies to Incident, Problem, and Change, because they extend Task. Check it when the rule is genuinely common to the whole table family; leave it unchecked when the rule belongs to one table only, otherwise you will get surprising behavior on child tables.

- On load: when checked, the policy is evaluated when the form first opens, using the record's saved values. Leave this checked in almost all cases — without it, the form will not reflect the record's current state until the user changes a condition field, so a reopened record can show the wrong fields as mandatory or visible.

2. Multiple conditions and actions in one policy

Yes. One UI Policy has one condition set, and that set can contain multiple conditions combined with AND / OR. One UI Policy can also have many UI Policy Actions — each action targets one field and sets one behavior (mandatory, visible, or read-only, for example). There is no documented hard limit on the number of conditions or actions, but that is not a reason to pile everything into one policy. The practical rule is: one policy = one business rule. Example: "If Category is Network, show the Network field and make it mandatory" is one policy with one condition and two actions. If you add unrelated behaviors to the same policy, it becomes hard to debug when something stops working.

3. Catalog UI Policies

The same structure applies, but to catalog variables instead of table fields, and they run on the catalog request form (Service Portal), not on the platform form. When you click New in the UI Policy Actions related list of a Catalog UI Policy, each new action targets one catalog variable — so to control several variables, you add several action rows in the same policy. Conditions likewise reference the catalog item's variables. Evaluation is the same idea: when a variable's value changes (or the form loads, if On load is set), the condition is re-evaluated and the actions are applied or reversed. One key difference to remember: a normal UI Policy does not control catalog variables, and a Catalog UI Policy does not control platform form fields — use each one in its own context.

4. Order / execution sequence

Yes, the Order field controls the sequence, and it works the same way for normal and Catalog UI Policies: policies run in ascending Order (100 before 200 before 300), both on form load and whenever a condition field changes. This matters when two policies touch the same field — the later policy wins on that field. So use Order deliberately (leave gaps like 100, 200, 300 so you can insert a policy later), and avoid having two policies fight over the same field; if they must overlap, the higher-order policy should be the one whose behavior you want to prevail.

5. Identifying conditions from business requirements

In real projects, the conditions almost always come from the user story or functional specification — the Business Analyst or client states the rule in words, and the developer translates it. The translation pattern is: "When <field/variable> is <value>, then <field/variable> should be <mandatory / visible / read-only>." The "when" part becomes the condition, and the "then" part becomes the actions. Example from Incident: "When Category is Software, the Software version field must be shown and mandatory" — condition: Category is Software; actions: Software version is visible and mandatory. If a story does not state the rule that precisely, ask for it before building — guessing the condition is how UI Policies end up conflicting with each other.

One final caution that matters in real projects: UI Policies are client-side form behavior only. They do not enforce security — a field made read-only or hidden by a UI Policy can still be changed through an API, import, or background script. If a rule must truly be enforced, back it with an ACL or a data policy as well.

Regards,

Karimuddin

[BURLED]

excellent explation appreciated you

[kmohammed]

Hi Damodar — glad it helped! Good luck with your UI Policy practice, and feel free to post again if you run into a tricky scenario.

Regards,

Karimuddin

[Tarun Rekandar · Accepted solution]

Hi @BURLED,

Here is a simple real-time scenario that covers your questions.

Scenario: Network Incident and New Laptop Request

Incident form (Normal UI Policy)

1. Requirement: When Category = Network, the agent must fill in Affected Location and Impact Scope.
2. Condition: Category is Network
3. Actions (two in one policy): Affected Location is Visible and Mandatory, and Impact Scope is Visible and Mandatory.
4. Options used:

• On load: checked, so existing Network incidents show the fields when opened.
• Reverse if false: checked, so if the agent changes Category to Software, the fields hide and are no longer mandatory.
• Global: checked, so it applies to all views.
• Inherit: unchecked, since the fields exist only on Incident.

Laptop Request (Catalog UI Policies)

• Policy A: When Employee Type = Contractor, Contract End Date is Visible and Mandatory. For anyone else it stays hidden.
• Policy B: When Need Accessories = Yes, Accessory Type is Visible and Mandatory. If the user switches back to No, the field hides and its value is cleared (Clear value checked).
• Each variable gets its own action, added through New on the UI Policy Actions related list.

Order example

• Order 100: hide Accessory Type by default.
• Order 200: show Accessory Type when Need Accessories = Yes.
• Lower order runs first, so 200 overrides 100 and the field shows correctly.

How the requirement becomes a configuration
The BA writes: “When Category = Network, Location is mandatory.”

• “When” becomes the condition (Category is Network).
• “Then” becomes the actions (Location visible and mandatory).
• “Otherwise” tells you to check Reverse if false.

Accept the solution if it assisted you with your question & Mark this response as Helpful.

Regards,

Tarun