Script Includes are ServiceNow’s primary way to store reusable JavaScript that runs on the server. A Script Include can define a function or class and can be called from Business Rules, other server scripts, scheduled logic, or, when deliberately enabled, from client-side code through GlideAjax. For the ServiceNow Certified Application Developer path, the key design question is not simply how to create one. It is when reusable server logic belongs in a Script Include and how to expose it safely.
Current ServiceNow documentation explicitly recommends Script Includes for complicated or reusable server-side code rather than loading large amounts of logic through global Business Rules. They are loaded when requested, which supports cleaner organization and can reduce unnecessary work. The wider ServiceNow platform uses the same principle throughout development: business logic should have clear ownership, a predictable execution context, and a small interface to its callers.
Use Script Includes for reusable server-side logic
A Script Include is a good fit when several server-side scripts need the same calculation, lookup, validation, or helper behavior. Instead of copying the logic into multiple Business Rules, centralize it in one well-named function or class. That makes fixes consistent because every caller uses the same implementation and reduces the risk of several slightly different versions of the same business rule.
Do not turn every three-line script into a utility class. Reuse should be meaningful. If logic belongs only to one small Business Rule and is easy to understand there, moving it elsewhere can make the flow harder to follow. Script Includes are most valuable when they represent a coherent capability with a clear interface.
Reusable logic also reduces policy drift. If several Business Rules calculate the same eligibility decision separately, one may be updated while the others remain unchanged. A shared Script Include creates one authoritative implementation. That centralization should be balanced with dependency awareness: changing the shared method can affect every caller, so significant behavior changes need regression tests across the consuming flows, scripts, and integrations that rely on it.
Choose between function-style and class-style designs intentionally
Script Includes can expose a single function or define a class with methods. A function can be appropriate for one focused operation, while a class can group related behaviors and maintain shared initialization. Name the artifact after what it does, not after a generic label such as Utils1. Callers should be able to infer the purpose from the class and method names.
Classes are useful when related functions share dependencies or configuration, but large “everything utility” classes become difficult to test. Split unrelated capabilities. Good server-side design follows the same principles as the broader API design concept: consumers should see a small, understandable contract while implementation details remain behind it.
Class design should keep state minimal unless it is required. A class that accumulates unrelated values between methods can be difficult to understand and may encourage callers to depend on invocation order. Prefer methods with explicit parameters and clear return values. When initialization is needed, document what the object expects. Predictable objects are easier to test and safer to reuse from Business Rules, scheduled jobs, Scripted REST APIs, and other server contexts.
Keep business rules thin by delegating complex logic
Business Rules are triggered by record events, so they should make their purpose obvious. When a rule contains hundreds of lines of reusable logic, execution timing and maintenance become difficult to reason about. A better pattern is often a small rule that determines when the logic should run and then calls a Script Include that performs the substantial work.
This separation also improves testing. The server-side method can be exercised with controlled inputs, while the Business Rule can be tested for the correct trigger. Developers can then diagnose whether a defect is caused by event timing or by the reusable logic itself instead of debugging both at once.
Thin Business Rules also improve performance analysis. When the rule only checks conditions and calls a named method, logs and traces can reveal which reusable service performed the work. Large inline scripts obscure that boundary and encourage copied query logic. Treat the Business Rule as an event adapter and the Script Include as the reusable service when the logic is complex enough to justify separation.
GlideAjax exposes selected server logic to client scripts
A Script Include can be marked GlideAjax enabled so client-side code can call server logic without reloading the entire form. This is useful when the browser needs information that should be calculated or retrieved on the server. The interface should return only the data the client needs, not an entire record or large payload by default.
Client-callable logic expands the attack surface because the browser request can be manipulated. Validate parameters on the server and require appropriate authorization. ServiceNow can associate ACL protection with GlideAjax-enabled Script Includes, and developers should use that capability where sensitive operations are involved. The security principles in secure application development are directly relevant: never trust the client simply because your own form generated the request.
GlideAjax methods should be designed for asynchronous user experiences. Return compact data and let the client update only what it needs. Avoid long-running server work that blocks form interaction, and avoid making several client calls when one server method can return the required values safely. Good client-callable design improves both security and responsiveness because it reduces exposed methods and unnecessary round trips.
Application scope controls who can call a Script Include
In scoped development, the “Accessible from” setting helps determine whether a Script Include is available only within its own application or from other application scopes. Exposing a reusable class to all scopes may be appropriate for a deliberate shared service, but it should not be the default response to a cross-scope error.
Think of the Script Include as an internal API. If another application needs it, define the supported methods and the data they are allowed to touch. Keep implementation details private where possible. This makes cross-scope dependencies easier to understand and reduces the chance that future changes break unknown consumers.
Cross-scope exposure should include versioning discipline. If another application calls a public Script Include method, changing its name, parameters, or return format can become a breaking change. Keep public methods stable or introduce a new versioned method when behavior must change materially. Internal private methods can evolve more freely. This is another reason to expose a small API surface rather than making every helper callable across scopes.
Validate input and handle errors near the server boundary
Parameters can come from Business Rules, integrations, client scripts, or other applications. Validate required values and expected formats before using them in queries or updates. A reusable method that accepts arbitrary strings and builds dynamic logic without validation becomes a security and reliability risk for every caller.
Error handling should also be predictable. Decide whether a method returns a status, throws an exception, logs a message, or updates a record, and keep that behavior consistent. Callers should not need to guess what failure looks like. The same robustness that makes API calls reliable—clear inputs, clear outputs, and explicit failure handling—applies to reusable server logic.
Input validation should happen before queries and writes. If a method expects a sys_id, validate that it is present and represents a record the caller is allowed to act on. If it expects a limited choice, reject unexpected values rather than allowing arbitrary strings to flow into dynamic logic. Small validation checks at the shared boundary protect every caller and reduce the chance that one weak client script becomes a platform-wide defect.
Performance improves when reusable logic avoids repeated work
A Script Include may be called from loops, imports, flows, or high-volume record events, so inefficient queries can multiply quickly. Avoid querying the same data repeatedly inside loops. Retrieve what you need once, use indexed conditions where practical, and keep return payloads small. A method that performs well for one record may fail badly when called ten thousand times.
Do not optimize blindly, but know the expected volume. Instrument slow paths and test representative datasets. Reusable code deserves more performance attention than one-off logic because a small inefficiency can propagate across many callers.
Performance tests should mimic calling patterns, not only individual method execution. A query that takes 20 milliseconds looks harmless until a loop calls it five thousand times. Review whether the caller can pass a set of identifiers for batch processing, whether data can be cached within one transaction, and whether repeated lookups can be replaced with one aggregate query. Reusable methods should scale with the workflows that actually consume them.
Security and privileges should remain explicit inside reusable code
A server-side utility can become dangerous if it performs privileged actions on behalf of callers without checking whether those actions are appropriate. Do not assume that every caller already enforced authorization. Sensitive methods should be designed so their privilege expectations are clear and, where necessary, checked at the server boundary.
The ServiceNow CSA access model remains relevant for developers. Roles, ACLs, and application scope determine who and what can reach data, while Script Includes organize how code operates on that data. Reuse should never become a bypass around the platform’s normal security controls.
Privilege expectations should be documented in the method name or comments when they are not obvious. A utility that deletes records, impersonates behavior, or changes protected configuration should not look like an innocent lookup helper. Sensitive Script Includes should be owned by the relevant application and reviewed like privileged APIs. This helps prevent future developers from reusing a powerful method in contexts where the original security assumptions no longer hold.
CAD scenarios reward modular server-side design
When a scenario describes duplicated server logic, complicated Business Rules, or client code that needs a controlled server calculation, consider a Script Include. If the logic is called from the browser, use GlideAjax intentionally and protect the callable interface. If another application scope needs the method, expose only the necessary resource rather than broadening the whole application.
A strong Script Include has a narrow purpose, clear name, predictable inputs and outputs, and appropriate scope and authorization. Those traits make the application easier to test and upgrade. The object is not just to move code into a different record type; it is to create reusable server behavior that remains understandable as the ServiceNow implementation grows.
For CAD preparation, remember why Script Includes exist: they provide reusable, on-demand server logic with clear application and client-callable boundaries. The best answer to a scenario is not always ‘create a Script Include,’ but when logic is shared, complex, or needs a controlled server interface, it is often the right abstraction. Keep the interface small, the implementation testable, the scope explicit, and the security assumptions visible to callers.
Code review should pay extra attention to widely reused Script Includes because one defect can affect many callers. Document the main consumers, keep methods cohesive, and add automated tests where practical. Reuse increases leverage in both directions: a good fix improves every caller, while a bad change can create a broad regression. Treat shared server utilities as application infrastructure rather than miscellaneous snippets.