ServiceNow gives developers several places to put logic, and choosing the wrong execution layer is one of the fastest ways to create slow forms, duplicated rules, security gaps, and code that is difficult to test. Client Scripts, Business Rules, and Script Includes can all contain JavaScript, but they exist for different reasons. The useful design question is not “where can this code run?” It is “where must this rule be enforced, and who needs to reuse it?”
For ServiceNow CAD, execution context is foundational application design. Client logic can improve the form experience, but it cannot be trusted as the only enforcement point for critical data. Business Rules react to database operations on the server. Script Includes package reusable server logic so multiple callers can use the same behavior without copying code.
Start by separating user experience from enforcement
Some requirements exist mainly to help a person complete a form correctly. Hiding an irrelevant field, displaying a message, changing a choice list, or making a field appear mandatory based on another value can often be handled in the client. Other requirements protect data regardless of how the record is changed. Those belong on the server or in a policy mechanism that applies beyond one browser form.
This distinction matters because ServiceNow records can be changed through imports, integrations, APIs, background scripts, flows, mobile experiences, list editing, and other paths that may never execute a traditional form Client Script. A rule that must remain true for every update should not depend only on code in a browser.
Before writing any script, also ask whether a declarative feature already fits. UI Policies can handle many dynamic form behaviors. Data Policies can enforce certain data requirements across more than the standard form experience. Flow Designer can automate process work. Scripting should solve a requirement that is clearer or safer in code, not replace platform features by reflex.
Use Client Scripts for immediate form behavior
Client Scripts execute in the user’s browser and react to form lifecycle events. Current ServiceNow developer guidance describes common types such as onLoad, onChange, onSubmit, and onCellEdit. They are useful when the user should see an immediate response before the record is sent to the server.
An onChange Client Script might make a field visible when a particular request type is selected, clear a stale value when a dependency changes, or display a warning when the user chooses a risky option. An onSubmit script can perform client-side validation and prevent a form submission while the user corrects a problem. An onLoad script can adjust presentation when the form opens, although heavy onLoad logic can slow the point at which the form becomes usable.
Client Scripts should remain small and focused. They run in an interactive path where latency is visible. Repeated synchronous server lookups, excessive reference calls, or unnecessary global scripts can make the interface feel slow. ServiceNow guidance favors doing what can be done locally before making a server call and using asynchronous GlideAjax when server data is genuinely needed.
Use Business Rules for record-operation logic on the server
Business Rules execute on the server around database operations. Depending on configuration, they can run before or after a record action, asynchronously after the transaction, or in display/query-related contexts. That makes them suitable for logic that depends on a record being created, updated, deleted, queried, or displayed from the server side.
A before Business Rule can validate or set values before a record is committed. An after rule can react after the database change, particularly when related work depends on the saved state. An async rule can move non-immediate work out of the user’s transaction when the response does not need to block the save. A display rule can prepare server data for use by client logic through mechanisms such as g_scratchpad.
Business Rules are especially important when the same constraint must hold even if the update does not come from the normal form. A client warning can improve the user experience, but a server-side rule can re-check a critical condition at save time. ServiceNow’s own best-practice guidance uses this pattern for conditions that may change between form interaction and submission.
Keep Business Rules narrow. Use conditions so they do not execute on irrelevant updates, avoid recursive patterns such as unnecessary current.update(), and do not turn one rule into a library of unrelated helper functions.
Use Script Includes for reusable server-side behavior
Script Includes are the natural home for server-side functions or classes that multiple application components need. If the same calculation, lookup, validation helper, transformation, or integration wrapper appears in several Business Rules or UI Actions, moving that logic into a Script Include creates one implementation with multiple callers.
This separation improves testing and maintenance. A Business Rule can remain focused on when a condition occurs and delegate the business function to a Script Include. A Scripted REST API, scheduled job, Flow action, or another server-side component can call the same function without copying it. When behavior changes, the central implementation changes once.
ServiceNow developer guidance explicitly recommends Script Includes for reusable code rather than trying to call one Business Rule from another component. Business Rules are triggers; Script Includes are reusable logic. Confusing those roles creates tight coupling and makes execution harder to reason about.
Use GlideAjax when client logic genuinely needs server data
A Client Script cannot directly execute ordinary server-side APIs in the browser. When a form needs data or processing from the server, a client-callable Script Include can expose a controlled method and GlideAjax can call it asynchronously. The server runs the Script Include, returns the requested result, and the client updates the form when the response arrives.
This bridge is useful for targeted lookups or calculations that cannot be performed safely in the browser. It is not an excuse to move every field change into a server round trip. If five onChange scripts each call the server when a form loads, the user experiences the architecture as latency.
Design the Script Include as an API boundary. Return only the data the form needs, validate inputs on the server, respect application scope and access controls, and avoid exposing broad methods simply because they are convenient during development. A small interface is easier to secure and maintain.
Put security and data integrity where the browser cannot bypass them
Client-side logic should never be the only protection for sensitive data. ServiceNow’s developer guidance is explicit that client-side security is easier to bypass. Access Controls, server-side checks, table/application security, and appropriate platform permissions must protect data even when a caller does not use the normal form.
The same principle applies to mandatory business rules. Suppose a change to a production CI requires a valid approval reference. A Client Script can help the interactive user by showing the field, explaining the requirement, or preventing an obvious bad submission. But an API integration or background update may bypass that form. The server must still reject or handle the invalid state if the requirement is truly mandatory.
Good design often uses both layers: client-side guidance for fast feedback and server-side enforcement for integrity. The code is not duplicated if the responsibilities are different. The client explains what the user should fix; the server guarantees that invalid data cannot be committed.
Think about timing, transactions, and side effects
Execution location also determines what data exists and what side effects are safe. Before a record is saved, the database may not yet contain its final state. After save, related actions can use the committed record and its identifier. Asynchronous work reduces response time but cannot provide immediate feedback to the user. Client code has direct access to form state but not to trusted server-only data or unrestricted APIs.
When logic updates other records, sends notifications, or calls external systems, transaction boundaries become important. A rule that fires repeatedly during one update chain can cause duplicate actions. A poorly conditioned Business Rule can trigger itself through another update. A client script that assumes a server update has completed may race ahead of an asynchronous response.
Document these timing assumptions in code and tests. “Runs after save because it needs the record ID” is a maintainable reason. “It worked here when I tried it” is not.
Use a simple decision matrix for new logic
If the requirement changes form presentation or gives immediate guidance, start with a UI Policy or Client Script. If the requirement must be enforced for any record update, use an appropriate server-side mechanism. If a database event should trigger server logic, use a Business Rule with a tight condition. If several server components need the same behavior, place that behavior in a Script Include. If a Client Script needs a small amount of trusted server data, call a client-capable Script Include with asynchronous GlideAjax.
Then review performance and security. Ask how often the code runs, whether it introduces a network round trip, whether it handles bulk or integration updates, and whether a caller can bypass the rule. These questions usually reveal when code has been placed in the wrong layer.
Across the ServiceNow platform, maintainable scripting comes from respecting execution boundaries. Put user-experience logic near the user, trusted enforcement near the data, reusable server behavior in Script Includes, and cross-layer calls behind deliberate interfaces. The result is faster forms, clearer transactions, and code that can evolve without hidden dependencies.