⚔️ Client Script vs UI Policy vs Data Policy in ServiceNow

[Bhavesh Patil]

"Understand the Differences. Apply the Right One"

Hey #ServiceNowCommunity 👋

As developers working with dynamic form behavior in ServiceNow, one of the most common questions we face is:

"Should I use a UI Policy or a Client Script?"

Here’s your answer! And to go one step further, let’s also talk about Data Policies — another powerful, often underrated tool in your ServiceNow arsenal.

After reading this post, you'll be better equipped to choose the right approach for the right scenario — helping you build cleaner, faster, and more maintainable applications. 🙌

---

🧠 When to Use UI Policy

UI Policies are perfect for simple, client-side form manipulations, like:

• Showing or hiding fields

• Making fields mandatory or read-only

• Controlling field visibility based on values

They are declarative, easy to configure, and require little to no scripting.

✅ Use when logic is straightforward and doesn't require custom JavaScript.

---

🔍 When to Use Client Script

Client Scripts come in when you need more advanced, scripted logic:

• Evaluating multiple field conditions

• Running JavaScript (e.g., if, else, loops)

• Validating data before form submission (onSubmit)

• Implementing role-based conditions or referencing other records

🔧 They offer more control — but should be used judiciously to avoid impacting performance.

---

🛡️ When to Use Data Policy

Data Policies enforce server-side data integrity, no matter where the data is coming from:
simply say - Data Policies executes on the server side. which applies on List view.

• Forms

• List view

• Background scripts

---

📊 Quick Comparison: UI Policy vs Data Policy

Feature / Behavior	Client Script	UI Policy
Execution Scope	Client-side (Form only)	Server-side (All record operations)
Applies To	Forms only	Forms, List Views, APIs, Imports
Field Control: Mandatory	✅ Yes	✅ Yes
Field Control: Read-Only	✅ Yes	✅ Yes
Field Control: Visible	✅ Yes	❌ No
Script Support	✅ (Optional UI Policy Script)	❌ No scripting allowed
Real-Time Feedback	✅ Yes	❌ No (unless "Run on Client" is enabled)
Execution in List View	❌ No	✅ Yes
Best Use Case	Dynamic form behavior	Enforcing platform-wide data integrity

---

⚙️ Client Script vs UI Policy

Feature / Behavior	Client Script	UI Policy
Condition Builder	❌ Requires scripting	✅ No-code UI-based condition builder
Reverse if False	❌ Not supported	✅ Automatically reverts field changes
Field Attribute Control	Scripted via g_form APIs	Declarative configuration
Access Old Value (onChange)	✅ Yes	❌ Not available
Execute on Submit/Update	✅ (onSubmit, onChange)	❌ Cannot run on submit
Complex/Role-Based Logic	✅ Best suited	❌ Not ideal
Code Required	✅ Yes (JavaScript)	❌ Not required (unless using optional scripts)
Best Use Case	Advanced validations, dynamic or role logic	Simple show/hide, mandatory, or read-only controls

---

⚠️ Common Mistakes to Avoid

❌ Using a UI Policy for logic that needs to be enforced everywhere → Use a Data Policy instead
❌ Writing a Client Script when a simple UI Policy would suffice
❌ Forgetting to enable "Run on Client" in Data Policy if real-time validation is needed

---

💬 Final Thoughts

Each tool — UI Policy, Client Script, and Data Policy — has its own unique purpose.
Understanding where each shines helps you:

• Improve user experience

• Boost performance

• Reduce maintenance overhead

🎯 Start with declarative logic (UI/Data Policy), and use scripting only when needed.

---

Have you ever had to refactor logic between these tools?
Or have a clever trick for choosing the right one?

Let’s hear your experience — share it in the comments below 👇
Let’s learn from each other as a community! 💬

Mark as helpful if it added value — it truly means a lot!

[ererg]

Really appreciate this breakdown, tips especially helpful! 🙌

[ganeshbagul]

Great knowledge, helpful