This post could be too basic for most of you folks, but this for me, is a deserving topic to have a blog post for its own. To solve this riddle and confirm if the statement - "Duh! Client scripts run first, followed by UI policies" is precise, analyzing the behavior in action seemed to be the best way.
A client script and a UI policy were written to work on the 'State' field on the incident form.
Client script: Makes state mandatory
UI policy: makes state non-mandatory
Upon running the above config, the field ends up being non-mandatory, clearly implying that UI policies run at the last.
Twisting this config a bit by running the same through the script block in the UI policy, the same behavior prevails.
Now, let's level it up... We are adding two more validations - one client script and one UI policy, both running conditionally and onChange. This brings four validations in total as below:
The result:
Alerts on the incident form are:
Scenario #1: when no conditions are met
1. OnLoad Client script, no condition:
2. OnLoad UI policy, no condition:
3. conditional OnChange client script -isLoading:
Scenario #2: when conditions are met
1. OnLoad Client script, no condition:
2. Conditional UI policy:
3. OnLoad UI policy, no condition:
4. OnChange Client script - isLoading:
Did you expect this? well, frankly I didn't :)
The UI policies take precedence over the isLoading part of the onChange client script. Obviously, after the above happens, the onChange client script triggers when the mentioned field changes value.
DRUMROLL... and the winner is:
onLoad client scripts
onLoad UI policies with no conditions
Conditional onLoad UI policies (if the condition meets)
onChange client scripts - the isLoading part
onChange client scripts triggered upon change of field values
The reason why client scripts run first is probably because that is how ServiceNow has defined it to execute, as they do not have any define-able order (No order field for client scripts, UI policies have it)
Comments