Use client script or dictionary to make a field mandatory?

[Suggy]

I have a simple use case - on a NEW incident form, make the 'DESCRIPTION' field as mandatory so that user fills it and only then can submit the form. This is my only requirement (dont care about API's/integrations).

Also note - there is only 1 VIEW configured for incident form and description field is shown in this view.

Question - which is the preferred solution and why?

Use [onLoad client script/UI policy] OR [make it mandatory in Dictionary]

[Anurag Tripathi]

If this has to be mandatory only on the form then you need a Client side script, UI policy or Client script both would work but UI policy's are recommended and they are very optimized, also they can be anno code solution.

[Uncle Rob]

This CAN be done via UI Policy, so that rules out Client Script immediately.

The only time you pick Client Script over UI Policy is if you have conditions or actions only achievable via script.... such as adding field messages.

The real question is whether it should be a UI Policy or a Dictionary Override setting.
You determine this by permanence.  Is Description ALWAYS (NO exceptions) mandatory?  If so, you could go the dictionary override (override is on the Task Description entry, override mandatory and set to true for the table you're working on).  If there's any conditionality at all, you need the UI Policy.

[BillMartin]

To complement what others have mentioned, it's important to note the behavioral precedence between client scripts and UI policies in ServiceNow. Behaviorally, client scripts take precedence over UI policies, meaning client scripts execute first.

For example, if you test this by adding an alert in a client script and another in a UI policy, you'll observe that the client script executes first. This order of execution is crucial to understand when designing client-side logic, as it can affect how field behaviors and validations interact on the form.

Keep in mind that while both client scripts and UI policies operate on the client side, their use cases differ. Client scripts are more versatile and can include complex logic, whereas UI policies are ideal for declarative changes like making fields mandatory, visible, or read-only.

Understanding this precedence helps in debugging and designing a smooth user experience on the form.

🎥 Want to see this in action? Watch my live demo on YouTube, where I break down client scripts, UI policies, and more with practical examples! Don’t forget to like, subscribe, and comment.