UI Policy on CMDB Form

[JamesLindsay]

I'm stuck on something that is probably very simple and may be barking up the wrong tree with a client-based UI policy. I simply trying to set a reference field to a static value when conditions are true. If a choice field I have created (u_source) is one value or another (say, 1 or 2) of 5 choices, set the target reference field (u_target) to value 1=A or 2=B, otherwise if source is 3,4,5 leave it alone. This works great for new entry but fails when going back in and editing the record. That is if in a record that is source 3,4, or 5 I change it to 1, and then back to 3, the record keeps the target value from I change to 1, it forgets what it initially was when the source was 3. I've tried fixing this by setting the initial value when the form loads and trying to set it back if the source is change back to its initial value, but the method doesn't seem to work.

Initial

Change Source, hide target field because it is static/hardcoded

Change it Back because I did not mean to change the source.

Target should revert to initial value.

There is no saving the record involved. Just flipping the source value between choices, it is left with the target value from choice 1, or 2 depending on where I was before I went back to 3,4, or 5. Saving it at that point would be an incorrect update.

[Aqib4]

Hi @JamesLindsay ,

It seems like you're facing an issue with preserving the value of the target reference field (`u_target`) when editing a record in ServiceNow based on conditions defined in a client-side UI policy. This issue occurs when changing the source field (`u_source`) from values 1 or 2 to values 3, 4, or 5, and then back to values 1 or 2.

To ensure that the target reference field retains its value based on the conditions defined, you may need to implement a combination of client-side scripting and server-side scripting. Here's a suggested approach to handle this scenario:

1. Client-Side Scripting (UI Policy or Client Script)**:
- Define a client-side script (either UI Policy or Client Script) to trigger when the `u_source` field changes.
- In the script, check if the new value of `u_source` is 1 or 2.
- If the new value is 1 or 2, set the value of the `u_target` field accordingly (to A or B).
- If the new value is 3, 4, or 5, leave the `u_target` field unchanged.

2. Server-Side Scripting (Business Rule)**:
- Implement a server-side Business Rule that triggers on update of the record.
- In the Business Rule script, check if the `u_source` field is changed from 1 or 2 to 3, 4, or 5.
- If the `u_source` field is changed from 1 or 2 to 3, 4, or 5, revert the `u_target` field back to its initial value (the value it had before it was changed based on the UI policy).

By combining both client-side and server-side scripting, you ensure that the value of the target reference field (`u_target`) is properly handled both when initially setting it based on the `u_source` value and when reverting it back to its initial value if the conditions are met.

Remember to thoroughly test this solution in your ServiceNow instance to ensure that it behaves as expected in various scenarios and edge cases. Additionally, consider incorporating error handling and logging to aid in troubleshooting any potential issues.

Please hit helpful and accept this as a solution if solves your queries.

Regards: Raja Aqib

[Akshay Gupta2 · Accepted solution]

Hi @JamesLindsay 

To address the issue you're facing with setting the target reference field based on the value of the source choice field in ServiceNow, you may need to adjust your approach slightly to ensure that the target field is updated correctly both during initial entry and subsequent edits. Here's a suggested approach using Business Rules:

1. **Create a Business Rule:**
- Navigate to "Business Rules" under "System Definition" in ServiceNow.
- Create a new Business Rule with a suitable name, such as "Set Target Reference Field."
- Set the table to the table containing your source and target fields (e.g., the Incident table).

2. **Define the Conditions:**
- Configure the conditions for the Business Rule to trigger when the source field (u_source) is changed.
- Add conditions to check if the source field is changed to values 1 or 2.

3. **Define the Action:**
- In the Business Rule script, set the value of the target reference field (u_target) based on the value of the source field.
- If the source field is set to values 1 or 2, set the target field to values A or B accordingly.

4. **Handle Subsequent Edits:**
- To handle subsequent edits, you may need to add additional logic to check if the source field is being changed back to values 3, 4, or 5.
- If the source field is changed back to these values, reset the target field to its original value.

Here's an example of how the Business Rule script might look:

(function executeRule(current, previous /* previous */) {
var sourceValue = current.u_source.getDisplayValue();
var targetValue = current.u_target.getDisplayValue();

if (sourceValue == '1' || sourceValue == '2') {
// Set target field based on source field value
if (sourceValue == '1') {
current.u_target = 'A';
} else if (sourceValue == '2') {
current.u_target = 'B';
}
} else if (sourceValue == '3' || sourceValue == '4' || sourceValue == '5') {
// Reset target field if source field value is 3, 4, or 5
current.u_target = ''; // Set to the appropriate default value if needed
}
})(current, previous);

In this script:
- We check the value of the source field (`u_source`) to determine the action to take.
- If the source field value is 1 or 2, we set the target field (`u_target`) accordingly.
- If the source field value is 3, 4, or 5, we reset the target field to its original value or to a default value if needed.

Make sure to test this Business Rule thoroughly in a non-production environment to ensure it behaves as expected in various scenarios. Adjust the logic as needed to fit your specific requirements and field configurations.

Do give a thumbsup.

Regards,

Akshay