ServiceNow IntegrationHub & Spokes

IntegrationHub is the low-code engine behind almost every integration on this list. Master the connection → credential → spoke → flow pattern once and every other system becomes a variation of it.

• admin and an IntegrationHub subscription (Starter includes REST/Flow actions; Standard/Enterprise unlock spokes).
• For on-prem targets, a running MID Server.

Before the steps, it is worth knowing what the four pieces in that pattern actually are, because the words are used loosely and each one is a separate record you can get wrong.

A spoke is a package of prebuilt actions for one target system. A connection holds where the target is: the base URL, the instance, the environment. A credential holds how you authenticate to it, stored so nobody can read it back. And a connection and credential alias is a name that points at a connection and credential pair.

The alias is the piece people skip and it is the reason the whole model works. A flow refers to the alias, never to the connection directly. So the same flow, transported from development to test to production, points at a different target in each because the alias resolves differently there. Without it, you are editing flows during a release, which is exactly what you do not want to be doing.

• Open the ServiceNow Store, find the spoke (e.g. Jira, Slack, Microsoft), and click Get.
• Spokes install their actions, a Connection & Credential alias, and sometimes example flows.

• Go to Connections & Credentials → Credentials.
• Choose the type the target needs: Basic Auth, API Key, or OAuth 2.0 (Authorization Code for user context, Client Credentials/JWT for server-to-server).
• Store secrets here, never hard-code them in a flow.

Where a credential can be used is worth restricting as well as where it is stored. A credential record can be tied to specific connections and to a MID Server, so an account created for one integration cannot be picked up by a flow somebody builds later for something else. That constraint costs nothing to set and prevents the slow drift where one convenient account ends up authenticating half a dozen unrelated integrations.

• Under Connection & Credential Aliases, open (or create) the alias the spoke uses.
• Add a Connection record: base URL of the target, the credential from Step 2, and Use MID Server if on-prem.
• The alias is the key idea, flows reference the alias, so you can swap dev/test/prod connections without editing flows.

Worth stating the consequence plainly: get the alias right and promotion is uneventful. An update set carries the flow and the alias definition, and each environment holds its own connection and credential records pointing at its own target. Nobody edits anything after a deployment, and nobody accidentally ships production credentials into a test instance.

An afternoon, and it proves the part that matters, which is not the flow but the promotion.

1. In a development instance, install a spoke for any system you have test access to, and create the connection, credential and alias.
2. Build a flow with one spoke action, triggered manually, and run it.
3. Check the target system directly to confirm it did what the flow says it did.
4. Now look at the flow's execution details. Read the inputs and outputs of the action, because that is what you will be reading when something fails.
5. Capture the flow and the alias in an update set and move it to a second instance that has its own connection record pointing somewhere else.
6. Run it there without editing anything. If you had to change the flow, the alias is not configured correctly and that is the finding.

Step six is the whole exercise. A flow that works in development and needs hand editing in production is a flow that will eventually be edited wrongly. See spokes.

• In Flow Designer, create a flow with a trigger (record created/updated, scheduled, or inbound).
• Add the spoke's action (e.g. Create Issue), pick the connection alias, and map inputs from the trigger.
• Use the action's outputs (IDs, status) in later steps, e.g. write a returned key back to the record.

One design habit is worth adopting from the first flow: handle the failure branch explicitly rather than letting the flow stop. A flow that ends in error leaves whatever it was doing half done and tells nobody, whereas a flow that catches the error can record it on the record it was working on, notify the right group, and leave something for a person to act on. It is a few extra minutes per flow and it is the difference between an integration that is supportable and one that is archaeology.

• Add the REST step (or a Scripted REST resource for inbound) and point it at the alias.
• This covers any API without a packaged spoke.

// Outbound REST via a connection alias (flow REST step)
Method:  POST
Connection: {alias}
Resource path: /rest/api/2/issue
Headers: Content-Type: application/json
Body: { "fields": { "summary": "{{trigger.record.short_description}}" } }

The decision worth making deliberately is how far to go before writing code. In order of preference: use a spoke if one exists; build a custom action in the same framework if it does not, which keeps the inputs, outputs and error handling consistent; and only then write a script. Each step down that list is more capability and more that somebody has to maintain and understand at three in the morning.

Two things people underestimate about generic REST. Pagination has to be handled by you, so an endpoint returning the first fifty of six hundred records will look like it worked. And rate limiting has to be respected, because a flow looping over records will happily issue requests faster than the target permits and be throttled or blocked.

• For a reusable in-house API, create a scoped app, define Flow Actions with typed inputs/outputs, and publish them as your own spoke.

• Use Flow Designer → Test and inspect Executions for each step's input/output.
• Check Outbound HTTP Requests logs for the raw call and response.
• Capture the connection, flow and actions in an update set; re-point the connection alias in each environment.

• Flows pointing at connections instead of aliases. Every promotion becomes a manual edit.
• Credentials in a script. Unrotatable and visible to anybody who can read the script.
• Ignoring pagination. The first page looks like the whole answer.
• Scripting where a custom action would do. More code, no more capability.
• Alerting on errors only. A dead integration is silent.

Building a flow takes an afternoon, and designing one that promotes cleanly and tells somebody when it stops working is the practice the course builds.