ServiceNow client script vs UI policy ||

Поделиться
HTML-код
  • Опубликовано: 7 фев 2025

Комментарии • 15

  • @psrpvm1034
    @psrpvm1034 Год назад +1

    Sir super you told as secret super as**its not ui actions** its ui policy

  • @amalasanthoshini1677
    @amalasanthoshini1677 2 года назад +1

    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.

  • @sadgunaparimi9424
    @sadgunaparimi9424 Год назад +1

    ui policy with runs next to client script right? but you told reverse

  • @gurukiranshetty5416
    @gurukiranshetty5416 2 года назад +1

    It is possible to set values of field using ui policy?

    • @SKfacts_ITcareers
      @SKfacts_ITcareers  2 года назад +1

      Yes , using run script in UI policy but I don't be suggested way

    • @gurukiranshetty5416
      @gurukiranshetty5416 2 года назад

      @@SKfacts_ITcareers thank you sir

    • @jakobdonathellmann7192
      @jakobdonathellmann7192 2 года назад

      @@SKfacts_ITcareers why you do not suggest it? Is it because it is not best practice? Or is there a technical foundation to it?

  • @keerthis3707
    @keerthis3707 2 года назад

    Hi sir,
    How about On change and onsubmit client script, When will it be executed? before or after UI policy?

    • @jakobdonathellmann7192
      @jakobdonathellmann7192 2 года назад

      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)😁

    • @keerthis3707
      @keerthis3707 2 года назад

      @@jakobdonathellmann7192 Good to see your work ..!! thanks for your detailed explanation jakob.

    • @jakobdonathellmann7192
      @jakobdonathellmann7192 2 года назад

      @@keerthis3707 Your welcome ;)

  • @spiritualenlightenment9857
    @spiritualenlightenment9857 2 года назад +1

    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 ?

    • @SKfacts_ITcareers
      @SKfacts_ITcareers  2 года назад +2

      If all 10 fields have same condition to set mandatory, ui policy only good option

    • @jakobdonathellmann7192
      @jakobdonathellmann7192 2 года назад

      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 ;)