Script step
Summarize
Summary of Script step
The Script step in Workflow Studio allows ServiceNow customers to add custom JavaScript code within reusable actions, enabling behavior beyond the capabilities of core action steps. This feature is available to users with theactiondesignerrole and is accessible as an action step in Workflow Studio. It supports execution on the ServiceNow instance, MID Server, or using core JavaScript, depending on the selected runtime environment. Integration Hub activation is required to access certain runtime and MID Server options.
Show less
Key Features
- Runtime Selection: Choose where the script executes—on the instance (default), on a MID Server, or using vanilla core JavaScript without ServiceNow APIs.
- MID Server Configuration: When selecting the MID Server runtime, you can specify which MID Server or cluster to use via auto-selection, specific MID Server, or MID Cluster. You can also filter eligible MID Servers by application support and capabilities. Connection aliases simplify credential management across environments.
- Input and Output Variables: Define named input and output variables to map data between Workflow Studio and the script. Inputs allow scripts to consume data from prior steps or action inputs, while outputs expose results to subsequent steps.
- Script Structure: Scripts access inputs and outputs via global objects named
inputsandoutputs. Variables should avoid reserved system names to prevent conflicts. Script outputs are converted to strings, with JSON data handled as strings or parsed within the script. - Error Handling: Configure the action’s behavior if the script step fails, choosing to either continue or trigger error evaluation.
Practical Use and Benefits
ServiceNow customers can use the Script step to incorporate custom logic tailored to unique business needs that core steps do not cover. By mapping inputs and outputs, scripts integrate seamlessly with other Workflow Studio steps, enabling complex workflows. Runtime options provide flexibility in accessing ServiceNow APIs or external resources via MID Servers. Using connection aliases enhances security and simplifies maintenance across environments.
For example, scripts can build JSON payloads dynamically for use in subsequent REST steps (which require Integration Hub). This capability allows customers to efficiently prepare data for external integrations within workflows.
Requirements and Considerations
- Integration Hub subscription is required to run scripts on MID Servers and to use REST steps.
- Users must have the actiondesigner role to create or modify Script steps.
- Ensure scripts avoid reserved system field names for input/output variables.
- Workflow Studio executes scripts in the domain context where the workflow is initiated, respecting domain separation rules.
Add custom JavaScript to execute within a reusable action. While most core actions and steps fit common use cases, you can build a Script step to execute behavior not satisfied by the core steps.
Roles and availability
Fields
The Script step includes separate input and output variables that enable you to map JavaScript data to Workflow Studio data. By defining input and output variables within the step, you can define what Workflow Studio data is available within your script, and which scripting variables are available to other steps in your action.
| Field | Description |
|---|---|
| Required Runtime | The runtime environment required to support the script.
Choices include:
The runtime you select determines the JavaScript objects and methods displayed in the Context-sensitive help. Note: This field is only visible when Integration Hub is activated. |
| Select MID Server Using | Specify the MID Server selection process to use. Choices include:
Note: This field is only visible when Integration Hub is activated, and you select MID from Required Runtime. |
| Connection Alias | Connection & Credential alias record that the system uses to run the action step. Users with the flow_designer or admin role can create or select an associated Connection record.
Using an alias eliminates the need to configure multiple credentials and connection information profiles when using an action in multiple environments. Likewise, if the connection information changes, you don't
need to update your custom action. To learn more about connections and credentials, see credentials, connections, and aliases. Only aliases of connection type Basic are supported. Note: This field is only visible when Integration Hub is activated, and you select Use Connection Alias from Select MID Server Using. |
| Host | The fully-qualified domain name of the MID Server where the system runs the action step. For example, mid-server.domain.com.
Note: This field is only visible when Integration Hub is activated, and you select Use Inline Selection from Select MID Server Using. |
| MID Selection | Option to select a specific MID Server or MID Cluster. Choose any one of the following options.
|
| MID Cluster | Data pill for the MID Cluster you want to use. This field is available when MID is selected from the Required Runtime list, and Use Inline Selection is selected from the Select MID Server Using list. |
| MID Application | Specify the application the MID Server must support to be eligible for selection. The system runs the action step from a MID Server that supports the selected application. This field is only visible when Integration Hub is activated, Auto-Select MID Server is selected from the MID Selection list, and you select Use Inline Selection from Select MID Server Using. |
| Capabilities | Capabilities the MID Server must support to be eligible for selection. The system runs the action step from a MID Server that supports the selected capabilities. This field is only visible when Integration Hub is activated, Auto-Select MID Server is selected from the MID Selection list, and you select Use Inline Selection from Select MID Server Using. |
| Specific MID Server | Data pill of the required MID Server. This field is only visible when Integration Hub is activated, Specific MID Server is selected from the MID Selection list, and you select Use Inline Selection from Select MID Server Using. |
| Input variables | Name-value pairs that represent data from the action, enabling you to use action inputs and data from other steps within a script. |
| Script | Script that executes within the action. To access input and output variables in your script, use the global objects inputs and outputs. For example,
inputs.myVariable.Note: Script
step input and output names can't include any of the following reserved system names:
The Script step always converts data stored in the inputs and outputs global objects into strings. If your Script step needs to work with JSON data, you can use the
inputs global object to convert the JSON data into a string. Alternatively, you can define a JavaScript variable as a string rather than a JavaScript object. For example, this script
illustrates two ways you can output JSON data.
By default, Workflow Studio run scripts on the instance. To run script from a MID Server requires an Integration Hub subscription. Workflow Studio runs script from the domain from which it is triggered or initiated. See Domain separation and Workflow Studio. For available classes and methods, see the JavaScript API context-sensitive help or the API reference. |
| Output variables | Map JavaScript output to Workflow Studio data pills. Define output variables when you want other steps in the action to use the script output. |
Action error evaluation
- If this step fails
- Data type: Choice
Option to continue running the next step or go to error evaluation. To use the step status code or message for a custom action error condition, see Action error evaluation.
Example
This example builds a JSON payload that can be easily updated or changed and added to a subsequent REST step.
By creating an output variable that represents the payload, you can drag the [Payload] data pill into the REST step Body field.