UI policy

[Rishabh_N]

Hi everyone,
I have 3 UI Policies, and each of them contains around 8–9 UI Policy Actions (show/hide and mandatory conditions for variables). But the UI Policies are not working as expected.

I already checked the Order and also tried Reverse if false, but it’s still not working properly.

(It is for catalog item)

[Rafael Batistot · Accepted solution]

@Rishabh_N 

I can see your screenshots.

The issue happens because you are using the same variable in multiple UI Policies.

For example, the variable “department” is set to mandatory = true in one policy and mandatory = false in another. This is not correct, because when the request is created, the variable will always follow the first policy, and for other request types it will conflict.

Instead of creating separate UI Policies that contradict each other, you should create a single UI Policy with conditions combined using AND (and/or OR when needed).

This way the logic will be consistent, and the variable will only behave as expected based on the right conditions.

See  Allen explanation 

https://www.servicenow.com/community/developer-forum/catalog-ui-policies-and-multiple-choice-variabl...

[Rishabh_N]

hi @Rafael Batistot 

I have a Group Management catalog item where, based on Request Type (Create, Update, Retire) I want to show/hide and make some variables mandatory.

I created separate UI policies for each type, but the behavior is inconsistent sometimes fields show/hide correctly, sometimes they don’t, especially after reloading the form.

I tried using different policy orders but not working properly

i have attchaed screenshots

[Rafael Batistot · Accepted solution]

@Rishabh_N 

I can see your screenshots.

The issue happens because you are using the same variable in multiple UI Policies.

For example, the variable “department” is set to mandatory = true in one policy and mandatory = false in another. This is not correct, because when the request is created, the variable will always follow the first policy, and for other request types it will conflict.

Instead of creating separate UI Policies that contradict each other, you should create a single UI Policy with conditions combined using AND (and/or OR when needed).

This way the logic will be consistent, and the variable will only behave as expected based on the right conditions.

See  Allen explanation 

https://www.servicenow.com/community/developer-forum/catalog-ui-policies-and-multiple-choice-variabl...

[Rishabh_N]

@Rafael Batistot, @prerna_sh   actually i was able to achieve this functionality using a client script, and it’s working perfectly. But I’m not sure if this is considered a best practice, or if I should still try to achieve it using a UI policy. Can you suggest the recommended approach?

[MackI]

hi @Rishabh_N 

Based on your scenario, I have the following suggestion that you can evaluate----

It's understandable that you're encountering inconsistent behaviour with Catalog Client Scripts and UI Policies, especially after form reloads, as both run on the client-side and can impact the same variables. Your approach of using separate UI policies for each 'Request Type' (Create, Update, Retire) and adjusting their order is a common starting point, but the "sometimes they don't" issue points to deeper interaction conflicts.

To resolve this, you need to examine the interplay of these client-side controls, along with potential server-side influences. Here's what to look at in detail:

1. Re-evaluate Client-Side Execution and Interaction

Both Catalog Client Scripts and UI Policies modify forms directly in the user's browser, and their combined effect can be unpredictable if not managed carefully.

• Execution Order:

    ◦ onLoad Client Scripts execute first when the form loads.

    ◦ onChange Client Scripts fire when a specified variable's value changes.

    ◦ UI Policies are evaluated after onLoad Client Scripts and then re-evaluated whenever a variable listed in their conditions changes [previous conversation]. This means a client script could set a field's state, only for a UI Policy to immediately change it if its conditions are met.

• Overlapping Actions on the Same Variable:

    ◦ Visibility: Check if one UI Policy or Client Script tries to show a variable (e.g., g_form.setVisible('variable_name', true)) while another attempts to hide it (g_form.setVisible('variable_name', false)) under conditions that might sometimes overlap. ServiceNow applications, like Asset Management, use UI policies to control visibility, such as "Hide asset tag and serial num" or noting fields that are "hidden but present for UI Policy conditions purposes".

    ◦ Mandatory State: Similarly, investigate if one control makes a variable mandatory and another makes it optional. For example, in Change Management, there are default UI policies for "Mandatory Assignment Group field" and "Mandatory Close notes and Code fields when in the Closed state".

    ◦ Read-Only State: Confirm if there are conflicting actions on making a variable read-only or editable. Model Management includes UI policies like "Lock fields for Contract and Work" that set fields on the Model Category form to read-only.

• UI Policy 'Order' and 'Reverse if false':

    ◦ You mentioned trying different policy orders, but it's crucial to understand that a lower Order value signifies higher precedence. If multiple UI Policies apply to the same variable under overlapping conditions, the one with the lowest order will generally dictate the final state [previous conversation].

    ◦ The "Reverse if false" checkbox on a UI Policy automatically reverts its actions when its conditions are no longer met. If you have multiple policies, the "reverse if false" action of one could inadvertently conflict with the "execute if true" action of another, leading to the inconsistencies you observe.

2. Consider Server-Side Restrictions and Business Rules

A critical factor that can explain "sometimes they don't" behaviour, especially after form reloads or when specific conditions are met, is the presence of server-side restrictions that override client-side logic.

• Enforce Data Requirements Property: The system property com.snc.change_management.enforce_data_requirements, when set to true, enables additional server-side restrictions on UI Policy and Client Script controls that already exist in the User Interface. This means that even if your client-side scripts or UI policies attempt to set a field to a particular state, a server-side rule could enforce an overriding state, causing your client-side changes to appear inconsistent or to be reverted. This property directly impacts data modifications through various channels, including the UI, Workflow, REST/SOAP, JavaScript, and GlideRecord updates.

• Business Rules Affecting Field Values: Backend Business Rules can also set or modify field values on record insertion or update. For example, the "Populate Assignment Group based on CI/SO" business rule automatically populates the Assignment group field based on the Configuration Item or Service Offering, which triggers when the Assignment group and Assigned to fields are empty. If this rule fires and sets a value, it could then trigger a UI Policy on the client-side, or bypass a Client Script's intended action.

3. Recommended Approach for Resolution

Given the complexities, especially with an important variable like 'Request Type' controlling multiple other fields, it's often best to centralise and streamline your logic:

1. Consolidate Logic for 'Request Type':

    ◦ Instead of multiple UI Policies with potentially overlapping or conflicting conditions, consider using a single advanced UI Policy on the 'Request Type' variable with a scripted condition. This script can then handle all the setVisible, setMandatory, and setReadOnly actions for the dependent variables based on the selected 'Request Type' [previous conversation].

    ◦ Alternatively, use a single onChange Catalog Client Script on the 'Request Type' variable. This script would contain all the logic to show/hide and make fields mandatory for 'Create', 'Update', and 'Retire' types. This gives you explicit control over the order of operations within the script. ServiceNow's state model configuration for Change Management, for instance, allows using script includes (like ChangeRequestStateModel_normal) to define available states, next states, and canMove/moving functions for state transitions, demonstrating how complex logic can be centralised in scripts.

    ◦ Why this helps: Centralising the logic ensures that there's one definitive place to manage the field states for all dependent variables based on the 'Request Type'. This significantly reduces the chance of conflicting instructions that lead to "sometimes works, sometimes doesn't" scenarios.

2. Ensure Mutually Exclusive Conditions:

    ◦ If you choose to stick with separate UI Policies for different 'Request Types', ensure their conditions are strictly mutually exclusive. This way, only one UI Policy will ever apply for a given selection of 'Request Type', preventing conflicts. For example, condition builders in various contexts are noted to ensure simplicity and mutual exclusivity.

3. Review Default/Base System Configurations:

    ◦ Many ServiceNow applications install default Client Scripts and UI Policies. For example, Asset Management has client scripts like "Hide asset tag and serial num", and Model Management has "model_category change". Ensure your custom logic doesn't inadvertently conflict with these base system functionalities. When migrating to new workspaces like Service Operations Workspace (SOW), you are specifically advised to "check that user interface (UI) policies and client scripts of the ITSM Agent Workspace record are working in the SOW record" and to "cross-check the conditions in Advance view" if issues occur.

4. Debugging Steps:

    ◦ Browser Developer Tools: Use your web browser's developer console. Look for JavaScript errors that might stop scripts from executing fully. Add console.log() statements within your Client Scripts and the "Execute if true" and "Execute if false" sections of your UI Policies. This will help you trace the exact sequence of execution, the values of variables, and which policies/scripts are firing.

    ◦ System Logs: If the issue persists and appears to be server-side, review the system logs for any Business Rule errors or warnings related to the fields you are modifying. Logging is also specifically mentioned for policy conditions in base system change flows.

By systematically checking these areas and considering the impact of both client-side and server-side logic, you should be able to identify and resolve the inconsistencies in your Group Management catalog item. Prioritising a consolidated approach for managing dependent variables on the 'Request Type' is often the most robust solution.

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ ⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community, Let me know if this helps or not

[AndersBGS]

Hi @Rishabh_N ,

Have you verified that you don't have any other rules e.g. other UI Policies or client scripts interfering