Why do client scripts execute before UI Policies when both are client-side?

[y21ece179]

I’m trying to understand the exact behavior of form logic in ServiceNow. Both Client Scripts and UI Policies run on the client side, but I’ve observed that Client Scripts execute first, followed by UI Policies.

• I understand the documented execution order:

  • OnLoad: Client Scripts → UI Policies → UI Policy Actions → UI Policy Scripts
  • OnChange: Client Scripts → UI Policies → UI Policy Actions → UI Policy Scripts

  My question is about the reason behind this design. Both Client Scripts and UI Policies run on the client side and aim to improve user experience. Why did ServiceNow choose to execute Client Scripts first and then UI Policies?

  • Is it because Client Scripts are imperative and UI Policies are declarative?
  • Does this order ensure consistency or prevent conflicts?
  • Are there architectural or performance considerations that make this sequence necessary?

  I’m looking for an explanation of the underlying logic or design philosophy, not just the order itself. Any official documentation or insights from experience would be helpful.

[Deepak Shaerma · Accepted solution]

Hi @y21ece179 

Conflicts only arises when you do the same action with both of them.. 

​UI Policies are designed to be the definitive logic for UI behavior (Mandatory, Read-only, Visible).

While client script are often used to fetch data, perform complex calculations, or set initial field values based on backend logic (using g_form or GlideAjax).

Happy to help! If this resolved your issue, kindly mark it as the correct answer ✅ and Helpful and close the thread 🔒 so others can benefit too.

Warm Regards,

Deepak Sharma

Community Rising Star 2025

[Deepak Shaerma · Accepted solution]

Hi @y21ece179 

Conflicts only arises when you do the same action with both of them.. 

​UI Policies are designed to be the definitive logic for UI behavior (Mandatory, Read-only, Visible).

While client script are often used to fetch data, perform complex calculations, or set initial field values based on backend logic (using g_form or GlideAjax).

Happy to help! If this resolved your issue, kindly mark it as the correct answer ✅ and Helpful and close the thread 🔒 so others can benefit too.

Warm Regards,

Deepak Sharma

Community Rising Star 2025

[Carlos Petrucio · Accepted solution]

Great question. This execution order is intentional and part of ServiceNow’s design.

1. Imperative vs. declarative responsibility

Client Scripts are imperative by nature they execute procedural logic such as:

• setting or modifying field values

• performing validations

• controlling submit behavior

• triggering asynchronous calls

• deriving intermediate or final state

UI Policies, on the other hand, are declarative. They define how the UI should behave (mandatory, read-only, visible) based on conditions evaluated against the current form state.

Because of this, ServiceNow executes Client Scripts first, allowing all logic and data manipulation to complete before the UI rules are applied.

---

2. Preventing conflicts and ensuring consistency

If UI Policies were evaluated before Client Scripts:

• They could react to temporary or incomplete values

• Visual rules could be overridden immediately by script logic

• Fields might flicker between states (mandatory/read-only/visible)

• The UI could briefly enter an inconsistent state

Running Client Scripts first ensures that:

• The form reaches a stable, final state

• UI Policies evaluate consistent data

• Presentation rules do not conflict with procedural logic

---

3. Architectural separation of concerns

ServiceNow enforces a clear separation of responsibilities:

Layer Responsibility

Client Scripts	Logic, validation, orchestration
UI Policies	UI behavior and presentation

This separation only works reliably if logic executes first and the UI reacts afterward, not the other way around.

---

4. Performance considerations

From a performance standpoint:

• Client Scripts can be conditionally executed

• UI Policies are evaluated efficiently once the final state is known

This avoids unnecessary re-evaluations and improves overall form performance and user experience.

---

Summary

Client Scripts run before UI Policies because they:

• Define the final data state

• Prevent conflicts between logic and UI

• Ensure predictable and consistent behavior

• Support a clean, scalable architecture

This execution model makes form behavior deterministic, stable, and easier to maintain.

Thanks for the great question!

- Carlos Petrucio

ServiceNow Developer