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.
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
Existing CustomConfig
Due to changes made by ServiceNow, HappyCustomConfig script include needs to be linked to Scripted Extension Point starting from the application version 2.0.0 in Ticket-based and Proactive, 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.
Examples below is from Ticket-based application, in Proactive the linking needs to be done to x_pgo_happyportal.HappyProactiveCustomConfig, and 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.
Creating a new CustomConfig
If you don't have an existing customConfig or just want to create a new custom config you can start by creating an implementation of the Scripted Extension point for the application.
In the ServiceNow menu search for Scripted Extension Points then by filter with the API Name x_pgo you can find the HappySignals Extension Points.

Select the correct extension point and use the Create Implementation button at the Related Links menu to create linked Extension Instance. Make sure you are in the right Scope before Creating the implementation as it's created to the same Scope you are in.

This will create a script include that you can then edit and handle like a normal Script include. And it's linked to the correct extension point.

