ServiceNow
      Back to home
      1. Support
      2. Technical Guides
      3. ServiceNow

      ServiceNow Scripted Extension Points

      Scripted Extension Points (SEPs) in ServiceNow are a mechanism that allows to create customizable and pluggable logic within applications. They act like interfaces in traditional programming, enabling multiple implementations of a defined behavior.

      Scripted Extension Points

      Scripted Extension Points (SEPs) in ServiceNow are a foundational design pattern that enables to define flexible, modular, and extensible logic within applications. At their core, SEPs act like interfaces in traditional programming: they define a contract or structure that other scripts—called implementations—must follow. This allows to separate the definition of a behavior from its execution, making it possible to plug in different logic depending on the context, without altering the core application code. This is especially powerful in scoped applications, where maintaining boundaries between different modules or teams is crucial. 

      Thumbnail Image Create a visual flowchart illustrating how Scripted Extension Points are used in ServiceNow applications to enable different logic across scopes. The diagram should include: 1. A box labeled 'Scoped Application' at the top. 2. An arrow pointing to a box labeled 'Scripted Extension Point (Interface)'. 3. Multiple arrows branching from the interface to boxes labeled 'Implementation A (Scope X)', 'Implementation B (Scope Y)', etc., each with a note like 'Custom Logic'. 4. A box labeled 'Wrapper Script' that dynamically calls the implementations. 5. Optional: A user or system icon triggering the Wrapper Script. 6. Use ServiceNow branding colors (green, gray, white) and a clean, modern style.

      Multi scope implementations

      In ServiceNow, Scripted Extension Points (SEPs) support the creation of multiple implementations across different application scopes, allowing for highly modular and context-specific logic. Each implementation can reside in its own scope, enabling teams to extend or customize functionality without altering the original application. This is particularly useful in enterprise environments where different departments or regions may require unique behaviors. Additionally, within a single scope, you can register multiple implementations of the same extension point. These implementations can be executed sequentially, allowing for layered or chained logic—such as performing validation, transformation, and logging in separate steps. 

      CustomConfig changes

      Due to changes made by ServiceNow, HappyCustomConfig script include needs to be changed to Scripted Extension Point starting from the application version 2.0.0 in Ticket-based, version 1.2.0 in Portal Experience. If you are using a HappyCustomConfig you just need to link to the new Scripted Extension as an Extension instance, this can be done in sys_extension_instance table by creating a new instance and linking it to the x_pgo_happysignals.HappyCustomConfig  that came with the update.

      Example below is from Ticket-based application, in Portal Experience the linking needs to be done to x_pgo_happyportal.HappyPortalCustomConfig.

      Steps for doing this.

      First change the scope to where you have your CustomPortal script

      Open sys_extension_instance.list -> add New

      Create a new instance by selecting the existing CustomConfig as a Class attribute and as Point the x_pgo_happysignals.HappyCustomConfig 

      After this you need to go the Scripted Extension and check that there is only the new instance added as all instances are run and they are run in the order set by order numbers. 

      You can have multiple instances but note that all active ones are run in the order specified.