UI Policy and Client script best practice

[Keshav72]

Hi Folks,

I came across a scenario where I need to control the visibility and mandatory state of multiple fields.
This can be achieved using UI Policies, but in this case, I would need to create more than 10 UI Policies.

However, I’m able to achieve the same functionality using a single Client Script.

I understand that:

• UI Policies are a configuration-based, low-code/no-code approach.

• Client Scripts are a customization and scripting-based approach.

From a scalability and maintenance perspective, it seems easier to manage one Client Script rather than maintaining multiple UI Policies.

I would like to understand what would be the best practice in this scenario.
Should we go with multiple UI Policies for the sake of configuration, or is it acceptable to use a single Client Script for better maintainability?

Looking forward to your thoughts and suggestions.

Thank you
Keshav

[Dr Atul G- LNG]

Hi @Keshav72 

I will always prefer to use low-code/no-code solutions because they are out-of-the-box and easily adopted and maintained, especially if the platform undergoes any changes in the future.

In this case, i will say use UI policy.

[Community Alums]

Hi @

Yes, UI Policies are the recommended way when you're just showing/hiding, making fields mandatory, or read-only — because they are easier to understand, manage, and audit later by admins who may not know how to read scripts. They're declarative and clear — meaning you can see exactly what they're doing at a glance, and they follow the ServiceNow "no-code/low-code first" design principle.

However, when you say you’d need 10 or more UI Policies, and your conditions are getting too complex, it’s totally reasonable to consider a Client Script — especially if:

• The logic is centralized, meaning it's easier to change/update later.

• You’re maintaining it alone or within a skilled dev team.

• It actually reduces complexity instead of increasing it.

 Best practices-

• If your logic is simple and repeatable, stick to UI Policies.

• If it’s dynamic, shared logic, or too many combinations, a Client Script is okay — but keep it well-documented.

• Avoid mixing both approaches for the same fields (to prevent conflicts).

• Always comment your Client Script well if it’s replacing multiple UI Policies, so others understand why.

[Ankur Bawiskar]

@Keshav72 

UI policies are recommended for simple requirements and client scripts for medium to complex logic,

It depends on your customer requirement.

For your example I will suggest to use 1 client script rather than 10 UI policies

This helps in maintaining the code going forward and any enhancement can be directly done in 1 client script

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

[Robert H · Accepted solution]

Hello @Keshav72 ,

I recommend UI Policies, not matter how many you need to build. 

Creating a script can be a bit quicker than creating UI Policies in some cases, but that is usually a one-time activity.

Reviewing and trying to understand the logic happens more often, and just looking at the UI Policy Actions for a table will give you a great overview that no script can ever give. Especially if you make good use of the Short description field.

Need to update the logic because one of the fields no longer needs to be read-only? Just do list-editing in the above screen to get it done in 3 seconds.

Also, there are some strategies to reduce the effort for creating the UI Polies.

Do some of the fields have the same condition for making them visible/read only/mandatory? In that case you can handle this with a single UI Policy.

In Catalog UI Policies you can even show or hide an entire container with multiple variables inside with a single UI Policy Action.

Regards,

Robert