Why should i "Avoid using field script to UI Policy"?

[Diogo Furtado1]

Hi, scanning my US i got the warning message "Avoid using field script to UI Policy" and i didn't understood exactly why.

The "Documentation URL" on Table check field is empty. 
I want to understand some reasons to avoid Scripted Ui Policies.

Regards,

[MackI · Accepted solution]

hi @Diogo Furtado1 

I believe you are we'll and good.

Reasons to Avoid Scripted UI Policies-----

Scripted UI Policies can cause:

Performance issues due to client-side execution and frequent triggers.
Maintenance and debugging difficulties because they are hard to track and debug.
Upgrade issues due to potential conflicts with future ServiceNow upgrades.
Security risks as client-side scripts can be manipulated.
Violation of best practices as ServiceNow promotes a declarative approach.

Alternatives to Scripted UI Policies

Standard UI Policies (Declarative): Preferred for most UI changes.
Data Policies: Enforce data integrity rules.
Client Scripts: Use for advanced form interactions that can't be done declaratively.
Business Rules (Server-Side): Use for actions that don't directly affect UI.

In your scenario based on the image that you provided see my opinion below—

Recommendations:

Review Flagged UI Policies:
Check the UI Policies identified by the Health Scan that you provided on the image.
Understand the script's function and the field it affects.
Refactor to Declarative UI Policies:
Replace the scripted logic with standard UI Policy Actions, if possible.

If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer(Accepted Solution) ‌🌠‌ OR  mark it  Helpful ‌⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community

[AshishKM]

Hi @Diogo Furtado1 , 

Did you check that/(or those ) Catalog UI Policy, if there is some script part coming under this scan, and you need to review that.

-Thanks,

AshishKM

[jcmings]

In general, scripting is more "risky" than using the OOTB configuration methods. ServiceNow is trying to encourage you to leverage the OOTB UI Policy Actions because they will continue to support those during upgrades. 

There is a (small) chance that certain functions you use in scripts may not be supported in subsequent releases, or will be sunsetted over time. By using the OOTB configurations, you can avoid that risk.

[MackI · Accepted solution]

hi @Diogo Furtado1 

I believe you are we'll and good.

Reasons to Avoid Scripted UI Policies-----

Scripted UI Policies can cause:

Performance issues due to client-side execution and frequent triggers.
Maintenance and debugging difficulties because they are hard to track and debug.
Upgrade issues due to potential conflicts with future ServiceNow upgrades.
Security risks as client-side scripts can be manipulated.
Violation of best practices as ServiceNow promotes a declarative approach.

Alternatives to Scripted UI Policies

Standard UI Policies (Declarative): Preferred for most UI changes.
Data Policies: Enforce data integrity rules.
Client Scripts: Use for advanced form interactions that can't be done declaratively.
Business Rules (Server-Side): Use for actions that don't directly affect UI.

In your scenario based on the image that you provided see my opinion below—

Recommendations:

Review Flagged UI Policies:
Check the UI Policies identified by the Health Scan that you provided on the image.
Understand the script's function and the field it affects.
Refactor to Declarative UI Policies:
Replace the scripted logic with standard UI Policy Actions, if possible.

If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer(Accepted Solution) ‌🌠‌ OR  mark it  Helpful ‌⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community

[Ankur Bawiskar · Accepted solution]

@Diogo Furtado1 

UI policies are meant to handle simply logic such as making a field mandatory/visible/readonly etc based on some condition

If you require complex logic then you should go with client scripts

If my response helped please mark it correct and close the thread so that it benefits future readers.