Integration steps
Summarize
Summary of Integration steps
Integration steps enable ServiceNow customers to create custom actions that integrate with external systems by using Integration Hub. This functionality adds integration steps to Workflow Studio, allowing flows to run either on the ServiceNow instance or on a MID Server. A MID Server is essential for communicating with external applications, data sources, or services within your network.
Show less
Only users with Flow Designer admin or Connection admin roles can execute flows using Integration Hub. Steps that manipulate record data run on the instance, while those that interact with network systems run on a MID Server. The instance delegates processing to the MID Server via REST calls, and logs and execution statuses are viewable from both the instance and MID Server.
Available Integration Steps
- JDBC step: Sends SQL commands to relational databases via MID Server.
- JSON Builder step: Creates dynamic JSON payloads on the instance.
- Payload Builder step: Builds JSON/XML name-value pairs using dynamic data on the instance.
- PowerShell step: Runs PowerShell scripts on remote machines via MID Server.
- REST step: Sends outbound REST web service requests, running on instance or MID Server.
- SOAP step: Sends outbound SOAP web service requests, running on instance or MID Server.
- SSH step: Executes SSH commands on external nix systems through MID Server.
- XML parser step: Parses XML payloads into complex objects on the instance.
Connection Attributes and MID Server Selection
Connections to external systems are managed via Connection & Credential aliases, which centralize connection details and simplify updates across actions. These aliases expose attributes as data pills in Workflow Studio for easy use in integration steps. MID Server selection can be manual or automatic, with options for load balancing and fail-over clusters.
It is recommended to avoid frequently shifting execution between different MID Servers during flow runs. Instead, configure MID Servers to handle multiple endpoints or capabilities to ensure stability and efficiency. Connection and credential administration roles may be required to update these configurations.
Design Considerations
- Avoid switching execution environments between the instance and MID Server multiple times within a flow; group similar steps together.
- When building spokes using integration steps, include Connection and Credential aliases and ensure they are associated with the correct connection records by users with the connectionadmin role.
- Avoid using Reference-type inputs for MID Server steps because MID Server only accesses the sysid; instead, provide necessary GlideRecord values explicitly.
Roles and Permissions
- Creating integration steps requires actiondesigner or admin roles.
- MID Server users must have connectionadmin and credentialadmin roles to access connection and credential information necessary for running steps.
Enable custom actions to integrate with external systems by activating Integration Hub, which adds integration steps to the Workflow Studio interface.
Steps that perform operations on record data run on the instance, while steps that integrate with systems in your network run on a MID Server. If a step requires a MID Server to run, the instance delegates flow processing to the appropriate MID Server by sending the process plan in a REST call. The MID Server executes the action or step in the process plan and returns results. View log messages and execution status from the instance or the MID Server.
Available integration steps
These integration steps are available from Workflow Studio - Building custom actions.
| Integration step | Description | Step runs from |
|---|---|---|
| JDBC step | Create a reusable action to send SQL commands to a relational database. | MID Server |
| JSON Builder step | Create a JSON payload to use in another step. Enter values or use data pills to produce a dynamic payload. This step supports several data types, including objects and arrays for nested structures. | Instance |
| Payload Builder step | Enable action designers to easily create name-value pairs in JSON and XML payloads using dynamic data. |
|
| PowerShell step | Run PowerShell scripts on remote machines from your ServiceNow instance through a MID Server. | MID Server |
| REST step | Send an outbound REST web service request to an external system. |
|
| SOAP step | Enable action designers to send outbound SOAP web service requests to external systems. |
|
| SSH step | The SSH step executes SSH commands on an external *nix system through a ServiceNow® MID Server. The step also stores scripts and commands for the *nix systems. | MID Server |
| XML parser step | Identify structured data from an XML payload without having to write script. Map incoming XML elements to a complex object output that you can use in other steps or actions. At runtime, values from an XML payload populate the complex object output. |
|
Training
Complete a step-by-step training on using the REST step in the REST in IntegrationHub developer training.
Connection attributes
Define connection-specific variables that you can use in Integration Hub integration steps. When using an integration step, you must establish a connection with an external system. Use a Connection & Credential alias instead of defining the connection inline. An alias enables you to update the connection details once without having to reconfigure every action. Any action step that uses an alias inherits the attributes associated with it. Workflow Studio displays attributes as data pills that you can drag into your action step. For example, you can create a page size attribute that becomes a REST step query parameter. For more information about connection attributes, see Create connection attributes for IntegrationHub.
MID Server connection aliases
Action designers can set MID Server selection attributes using a connection record associated with an alias and associate the alias with an integration step. When the flow runs, the system uses the attributes to determine which MID Server runs the step. Learn more about Introduction to credentials, connections, and aliases.
MID Server and MID Cluster selection
For most integration steps, you can specify a MID Server or MID Cluster for the step to use when it runs. For a MID Server, you can select one you've configured or have the system choose one by selecting Auto-Select MID Server from the step's MID Selection list. To learn more about how a MID Server is selected during runtime, see MID Server selection. For MID Clusters, you can select a load-balancing or fail-over cluster for the step. For more information on MID Clusters, see Configure a MID Server cluster. The Payload Builder step and XML Parser step do not support MID Server selection.
When specifying a MID Server, Flow designers should avoid shifting the execution environment from one MID Server to another when a flow runs. Either configure each MID Server to perform operations on multiple endpoints, or provide multiple capabilities to each MID Server in your network. You may need a user with the connection_admin role to update the connection records associated with an action, or a network administrator to update the MID Server network configuration.
Design considerations
Design integration steps using the following guidelines.
- Avoid shifting the execution environment between the instance and the MID Server multiple times. Where possible, group similar action steps. For example, group core steps that perform record operations and integration steps that run on the MID Server.
- When creating a spoke that uses an integration step, include a Connection and Credential alias record with the appropriate connection type. Before anyone can use the spoke, a user with the connection_admin role must associate the alias record to a connection record that supports the connection type. If defining the connection inline, use inputs to enable the process analyst to define the connection information when adding the action to a flow.
- The MID Server does not have access to all the values in a GlideRecord object, it only has access to the sys_id reference. Inputs of type Reference do not work on a MID Server. Instead, create action inputs that contain the necessary GlideRecord values.
Roles
To create integration steps, a user must have the action_designer or admin roles. If running steps on a MID Server, the MID Server user must have the connection_admin and credential_admin roles to access the connection and credential information associated with the step.