Hi I want to make it clear the one point. *Set field attributes with no scripting 1.In client scripts(CS) if we want to make the field mandatory, read only or visible scripting is required, without scripting we can't do CS so answer is no. 2.In ui policy we can do it without scripting soo answer is yes.
Hey Keerthi S After further research, I found this great post in the ServiceNow community forum: A Race between UI Policy and Client script (www.servicenow.com/community/developer-blog/a-race-between-ui-policy-and-client-script/ba-p/2292668). It breaks down the execution order of UI Policies and Client scripts more detailed. I validated it in my personal developer instance and enhanced it a little bit: The following results bases on my experimental approach. It is hard to find real documentation on the technical behavement from Client scripts and UI Policies. 1) When a form loads, the order of execution looks as follows: 1. Onload() Client scripts 2. UI Policies with conditions being true when the form loads (On load activated) 3. UI Policies without conditions (On load activated) 4. OnChange() Client scripts with code in the isLoading() property. The last fact is interesting, because the docs actually tells you that Client Scripts get executed before UI Policies. But on load it behaves differently as you can see. 2) When a fields value is changed, the execution order is like it should be: 1. OnChange() Client scripts targeting the changing field 2. UI Policies with true conditions for the changing field. 3) When it comes down to OnSubmit() Client scripts, it gets a little more complicated. For that case, have a look on the following OnSubmit() Client scripts function: function onSubmit() { alert("OnSubmit() Client script bevor field value changes"); g_form.setValue('priority',2); //example field change, on which the UI Policy will trigger alert("OnSubmit() Client script after field value changed"); }; If you now submit an example form, the execution order will work as follows: 1. OnSubmit() Client script is called first. Displays first message ("OnSubmit() Client script before field value changes"). 2. OnSubmit() Client script changes field value. 3. UI Policy is triggered and executes (displayes an example message like "UI policy got executed"). 4. OnSubmit() Client script displays second message ("OnSubmit() Client script after field value changed"). _______________________________ So all in all, I hope I could give you and others a more clear picture on the execution logic of Client scripts and UI Policies. If so, I would be glad to have a little feedback from your side (like and/or comment please)😁
So for that simple case, in terms of functionality and execution speed, it is theoretically irrelevant whether you are using UI Policy or Client Script. It is just important to know, that OnChange() Client scripts trigger before UI Policies. And if you want to have your fields mandatory before other Client scripts execute, you should use a Client script to set the fields mandatory and lower its order value, which will affect that it will be executed before other Client scripts. But if no other OnChange() Client scripts on the condition field exists or it is irrelevant to you if they execute first, best practice is to use a UI Policy for the job. However, in terms of production speed, I would probably take the Client script, because clicking your UI Policy Actions together takes time ;)
Sir super you told as secret super as**its not ui actions** its ui policy
Thank you
Hi
I want to make it clear the one point.
*Set field attributes with no scripting
1.In client scripts(CS) if we want to make the field mandatory, read only or visible scripting is required, without scripting we can't do CS so answer is no.
2.In ui policy we can do it without scripting soo answer is yes.
ui policy with runs next to client script right? but you told reverse
It is possible to set values of field using ui policy?
Yes , using run script in UI policy but I don't be suggested way
@@SKfacts_ITcareers thank you sir
@@SKfacts_ITcareers why you do not suggest it? Is it because it is not best practice? Or is there a technical foundation to it?
Hi sir,
How about On change and onsubmit client script, When will it be executed? before or after UI policy?
Hey Keerthi S
After further research, I found this great post in the ServiceNow community forum: A Race between UI Policy and Client script (www.servicenow.com/community/developer-blog/a-race-between-ui-policy-and-client-script/ba-p/2292668).
It breaks down the execution order of UI Policies and Client scripts more detailed. I validated it in my personal developer instance and enhanced it a little bit:
The following results bases on my experimental approach. It is hard to find real documentation on the technical behavement from Client scripts and UI Policies.
1) When a form loads, the order of execution looks as follows:
1. Onload() Client scripts
2. UI Policies with conditions being true when the form loads (On load activated)
3. UI Policies without conditions (On load activated)
4. OnChange() Client scripts with code in the isLoading() property.
The last fact is interesting, because the docs actually tells you that Client Scripts get executed before UI Policies.
But on load it behaves differently as you can see.
2) When a fields value is changed, the execution order is like it should be:
1. OnChange() Client scripts targeting the changing field
2. UI Policies with true conditions for the changing field.
3) When it comes down to OnSubmit() Client scripts, it gets a little more complicated.
For that case, have a look on the following OnSubmit() Client scripts function:
function onSubmit() {
alert("OnSubmit() Client script bevor field value changes");
g_form.setValue('priority',2); //example field change, on which the UI Policy will trigger
alert("OnSubmit() Client script after field value changed");
};
If you now submit an example form, the execution order will work as follows:
1. OnSubmit() Client script is called first. Displays first message ("OnSubmit() Client script before field value changes").
2. OnSubmit() Client script changes field value.
3. UI Policy is triggered and executes (displayes an example message like "UI policy got executed").
4. OnSubmit() Client script displays second message ("OnSubmit() Client script after field value changed").
_______________________________
So all in all, I hope I could give you and others a more clear picture on the execution logic of Client scripts and UI Policies.
If so, I would be glad to have a little feedback from your side (like and/or comment please)😁
@@jakobdonathellmann7192 Good to see your work ..!! thanks for your detailed explanation jakob.
@@keerthis3707 Your welcome ;)
I have a one question for you? if I want to set mandatory in 10 fields so what we can use UI policy OR client script ?
If all 10 fields have same condition to set mandatory, ui policy only good option
So for that simple case, in terms of functionality and execution speed, it is theoretically irrelevant whether you are using UI Policy or Client Script.
It is just important to know, that OnChange() Client scripts trigger before UI Policies. And if you want to have your fields mandatory before other Client scripts execute, you should use a Client script to set the fields mandatory and lower its order value, which will affect that it will be executed before other Client scripts.
But if no other OnChange() Client scripts on the condition field exists or it is irrelevant to you if they execute first, best practice is to use a UI Policy for the job.
However, in terms of production speed, I would probably take the Client script, because clicking your UI Policy Actions together takes time ;)