ServiceNow Script Include Scripting Using JavaScript


Script Includes can reveal their real power quickly. You can utilise and call them from Scheduled Jobs, Business Rules, UI Actions, Transform Maps, and even from other Script Includes. They are versatile, as they can be accessed from the client’s end.


So, what are Script Includes? According to the documentation, “Script Includes are used to store JavaScript that runs on the server.” You might wonder how JavaScript code gets executed on the server. This is where Rhino kicks in: It is an interpreter that generates Java code from your JavaScript.

Where to begin exploration? Navigate to System Definition –> Script Includes. Provide a descriptive name, add a meaningful description (if applicable), and implement the feature accordingly. Should you use a function or a class? We will get back to this later.

This is all fine and straightforward, but what is the advantage of this? Let us dive into a fictional scenario and see how Script Includes come to the rescue.

Example Use Case

So, you need to create a Scheduled Job. It is not a big deal: The task is well defined; you finish with the implementation soon. Now, it is time for thorough testing.

But, to achieve this, you need to set your Scheduled Job to “On Demand” execution for a while –that is just OK.

Then, you need to apply some changes for the sake of testing and easier inspection, such as narrowing the scope or changing the default date parameters such that only a subset of records are affected. Soon, your list of things that need to be reverted before going to PROD grows lengthy.

Suddenly, a new requirement appears: When some other events occur, the same logic should be applied as well. You are perhaps wondering how to achieve this, since when you receive another task similar to the present one, you copy and paste your Scheduled Job.

And this is the point at which you stop and start thinking about a different approach.

By using Script Includes, you can make the actual business logic independent from the usage. You can also decompose larger chunks of code into smaller blocks that are more maintainable and easily comprehensible. The feature can be utilised from other places as well, which helps re-usability.

Function-based vs. class-based approach

For the simplest cases, you could just create a function within your Script Include. However, when you require more than one function, there is an interesting gotcha: the 2nd and further functions are available to be called only after the first function has been called at least once. Moreover, using the same function names such as Update, Refresh, Load Data in multiple Script Includes will have a side effect: You will not face any error; instead, only the last referenced function will be called, which can be surprising and hard to resolve. So, you should usually go for the class-based approach. Hint: ServiceNow auto-generates a class stub for you when you create a new Script Include.


The more places you use your Script Include at, the more complex it will possibly become. Why? The reason is simple: You need almost exactly the same functionality, but with a little tweaking or further parametrisation. While this might work for a while, things tend to get messy soon. Do not be afraid to split your Script Includes. Life is about trade-offs: You might avoid code duplication with some all-purpose Script Includes, which is nice, but on the other hand, you might face monstrous code blocks that soon become too complex, fragile, and will be a pain to modify. Refactor the code when it seems to be useful. Extract well-defined components for separate classes, and thus, the original class will become smaller, easier to understand, and more maintainable. Or, even have some code duplication, when it seems to be more logical.

Good to know

  • To make your Script Include usable from the client side, use the class-based approach and extend
  • If you cannot use your Script Include (“MyScriptInclude is not defined”), check the “Accessible from” field. You should be in the same scope, or the script should be available to all application scopes.

For further reading

Blog post author: David@esmAlliance