--- sourceDocument: Australia Workflow Data Fabric sourceDocumentLink: https://www.servicenow.com/docs/r/australia/integrate-applications Release : - australia ft:locale : - en-US ft:publication_title : - Australia Workflow Data Fabric ft:clusterId : - crint bundleId : - crint workflow : - Creator --- # Integration steps # Integration steps {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Integration steps Integration steps enable ServiceNow customers to create custom actions that connect with external systems by activating Integration Hub. These steps appear in Workflow Studio and can run either on the ServiceNow instance or through a MID Server. A MID Server is essential for communication and data transfer between your ServiceNow instance and external applications or services within your network. Show full answer 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 interacting with networked external systems run on a MID Server. When a step requires a MID Server, the instance delegates execution via REST calls, with the MID Server performing actions and returning results. Logs and execution status can be viewed from both the instance and MID Server. ## Available Integration Steps The following integration steps are available from Workflow Studio and serve various purposes depending on whether they run on the instance or MID Server: * **JDBC step:** Sends SQL commands to relational databases (runs on MID Server). * **JSON Builder step:** Creates dynamic JSON payloads with various data types (runs on instance). * **Payload Builder step:** Builds JSON and XML payloads easily using dynamic data (runs on instance). * **PowerShell step:** Executes PowerShell scripts on remote machines via MID Server. * **REST step:** Sends outbound REST requests to external systems (runs on instance or MID Server). * **SOAP step:** Sends outbound SOAP requests (runs on instance or MID Server). * **SSH step:** Executes SSH commands on nix systems via MID Server. * **XML parser step:** Parses XML payloads into complex objects without scripting (runs on instance or MID Server). ## Connection Attributes and MID Server Selection Connections to external systems must be established using Connection \& Credential aliases rather than inline definitions. Aliases centralize connection management, allowing updates without reconfiguring every action. These aliases expose connection attributes as draggable data pills in Workflow Studio, enabling dynamic and reusable configurations such as query parameters. For steps requiring a MID Server, you can select a specific MID Server, use auto-selection, or specify a MID Cluster for load balancing or failover. The Payload Builder and XML Parser steps do not support MID Server selection. It's important to avoid changing the execution environment between different MID Servers mid-flow to maintain consistency and manageability. Configure MID Servers to handle multiple endpoints or capabilities as needed. ## Design Considerations * Group similar steps together to minimize switching between instance and MID Server execution environments. * Include Connection and Credential alias records when creating spokes using integration steps to facilitate proper connection management. * If using inline connections, provide inputs so process analysts can define connection information during flow configuration. * Note that MID Servers only have access to the `sysid` from GlideRecord objects, so inputs should avoid reference types and instead pass necessary values explicitly. ## Roles and Permissions To create integration steps, users need the **actiondesigner** or **admin** roles. When running steps on a MID Server, the MID Server user must have both **connectionadmin** and **credentialadmin** roles to access required connection and credential information. Enable custom actions to integrate with external systems by activating Integration Hub, which adds integration steps to the Workflow Studio interface. Integration steps can run on the instance or a MID Server. A MID Server is required to communicate with or move data between a ServiceNow instance and external applications, data sources, and services in your network. Note: Only Flow Designer admin and Connection admin can execute flows using Integration Hub. 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 {#integration-steps__section_gl4_f1t_rcb} These integration steps are available from [Workflow Studio - Building custom actions](https://www.servicenow.com/docs/access?context=actions&version=australia&pubname=australia-build-workflows&ft:locale=en-US). {#integration-steps__table_ypl_5zs_rcb__entry__3} | Integration step | Description | Step runs from | |-|-|-| | [JDBC step](https://www.servicenow.com/docs/QvOaDgh2ijSstxyLJN49ew "Create a reusable action to send SQL commands to a relational database.") | Create a reusable action to send SQL commands to a relational database. | MID Server | | [JSON Builder step](https://www.servicenow.com/docs/7pYqudqKWAfHH6znUnRWJA "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.") | 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](https://www.servicenow.com/docs/_Px9U~xv0wXGmoeUDy7mNw "Enable action designers to easily create name-value pairs in JSON and XML payloads using dynamic data.") | Enable action designers to easily create name-value pairs in JSON and XML payloads using dynamic data. | * Instance * MID Server {#integration-steps__ul_axh_gzl_tgb} | | [PowerShell step](https://www.servicenow.com/docs/qJDHoQdvlc_j~PZvpEHZug "Run PowerShell scripts on remote machines from your ServiceNow instance through a MID Server.") | Run PowerShell scripts on remote machines from your ServiceNow instance through a MID Server. | MID Server | | [REST step](https://www.servicenow.com/docs/eu3lP8HWXOLP2X8LBMvJuA "Send an outbound REST web service request to an external system.") | Send an outbound REST web service request to an external system. | * Instance * MID Server {#integration-steps__ul_ehl_yzs_rcb} | | [SOAP step](https://www.servicenow.com/docs/~lxQeTqLLVkQialozMRwng "Enable action designers to send outbound SOAP web service requests to external systems.") | Enable action designers to send outbound SOAP web service requests to external systems. | * Instance * MID Server {#integration-steps__ul_yhl_1zl_tgb} | | [SSH step](https://www.servicenow.com/docs/uKxPLIVCFStvqwRsRumuog "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.") | 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](https://www.servicenow.com/docs/XZVF9oqtywlVU1QnRnYdDg "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.") | 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. | * Instance * MID Server {#integration-steps__ul_jkc_b1m_tgb} | [ ] {#integration-steps__table_ypl_5zs_rcb} ## Training {#integration-steps__section_xmc_hpd_1jb} Complete a step-by-step training on using the REST step in the [REST in IntegrationHub developer training](https://developer.servicenow.com/dev.do#!/learn/courses/tokyo/app_store_learnv2_rest_tokyo_rest_integrations/app_store_learnv2_rest_tokyo_rest_in_integrationhub/app_store_learnv2_rest_tokyo_rest_in_integrationhub_objectives). ## Connection attributes {#integration-steps__section_qv2_tbz_hdb} 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](https://www.servicenow.com/docs/access?context=create-connection-attributes&version=australia&pubname=australia-platform-security&ft:locale=en-US). ## MID Server connection aliases {#integration-steps__section_v41_xns_rcb} 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](https://www.servicenow.com/docs/access?context=credentials-connections-alias&version=australia&pubname=australia-platform-security&ft:locale=en-US). ## MID Server and MID Cluster selection {#integration-steps__section_ghf_xns_rcb} 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](https://www.servicenow.com/docs/access?context=c_MIDServerSelector&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US). 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](https://www.servicenow.com/docs/access?context=t_ConfigureAMIDServerCluster&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US). 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. Note: If a selected MID Server is part of a cluster, the runtime MID may be different, depending on load. So even if a MID Server is specified at the connection or step level, a different MID Server in the same cluster may be used at runtime. ## Design considerations {#integration-steps__section_sr5_n4w_qcb} 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. {#integration-steps__ul_mxm_s4w_qcb} ## Roles {#integration-steps__section_egp_d3l_kcb} 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.