ServiceNow Spoke Explained

What Is a Spoke?

A Spoke is a deployment unit in ServiceNow’s workflow automation and integration capabilities. When you build a workflow or integration using ServiceNow’s platform, you can deploy it as a Spoke: a self-contained package that includes the workflow logic, configuration and any required integrations. This approach helps organisations share and reuse automation across their ServiceNow instance or across different instances.

Spokes simplify deployment and governance. Rather than each team building automation independently, they can use approved Spokes that have been validated and tested. This standardisation reduces errors, improves security and makes it easier to update automation across the organisation when underlying systems change.

Where Spokes Live in the Platform

Spokes are managed in ServiceNow’s Flow Designer or Integration Hub, depending on the type of automation. A Spoke is essentially a packaged workflow that can be published and shared. It includes the logic, any data lookups or transformations, and connection details for external systems. The platform provides tools to create, version, test and deploy Spokes.

Spokes can be organisational (available within your ServiceNow instance) or publicly shared (available to other ServiceNow customers). Most organisations build organisational Spokes for internal use: automation specific to their business processes, integrations with their specific systems, or workflows that handle their unique requirements.

A Worked Example

Consider an organisation that needs to send status updates to a project management system whenever certain changes happen in ServiceNow. Rather than each team building this integration independently, they could create a Spoke that handles the integration: it listens for changes, transforms ServiceNow data into the format the external system expects, and sends the update. Other teams can then use this Spoke without rebuilding the integration.

Another example: an approval workflow that involves multiple layers of approvers depending on the request type. Instead of rebuilding this workflow in multiple places, build it once as a Spoke. Then any process that needs this approval logic can use the Spoke instead of recreating it. If the approval rules change, update the Spoke once and the change takes effect everywhere it’s used.

Common Misunderstandings

A frequent misunderstanding is thinking Spokes are simple templates. They’re more than that: they’re executable packages that can integrate with other systems, perform complex transformations and manage state. Another confusion arises from mixing Spokes with Flows or Workflows: Spokes are one way to package and share automation, but not all automation is a Spoke.

Some organisations mistake Spokes for a way to avoid learning the platform. While Spokes can reduce repetitive work, understanding the underlying workflows and integrations is important for troubleshooting when Spokes don’t behave as expected or need customisation.

Spokes and Related Concepts

Spokes relate closely to Flows and Workflow automations. A Flow is a visual representation of a process; a spoke is a set of reusable actions for one third-party application. Integration Hub provides tools to build integrations that can be packaged as Spokes. Subflows are similar to Spokes but smaller: reusable pieces of logic that one Spoke might call.

Templates are different from Spokes: templates provide starting points, while Spokes are complete, ready-to-use automations. Catalogues can display Spokes to users, allowing self-service invocation of the automation. Understanding these relationships helps you use Spokes effectively.

Building and Maintaining Spokes

Building a Spoke starts with identifying a repeatable process or integration. Document the steps, identify data inputs and outputs, then build the Spoke using Flow Designer or Integration Hub. Test thoroughly with sample data to ensure it works correctly. Version the Spoke so you can track changes and roll back if needed.

Spoke maintenance is important. As external systems change, Spokes that depend on those systems may break. Regular testing catches these breaks early. Documenting Spoke logic makes it easier for other teams to understand and use them. Communicating Spoke changes to teams that use them prevents surprises.

Governance and Best Practices

Without governance, Spokes can proliferate: many similar Spokes for similar purposes, confusion about which Spoke to use, difficulty maintaining them. Best practice includes maintaining a catalogue of approved Spokes, documenting their purpose and usage, and governing Spoke creation so duplicates don’t accumulate. Some organisations designate a “Spoke owner” who maintains the catalogue and approves new Spokes.

Version control is important. When a Spoke is updated, teams using it need to know. Some updates are backward-compatible and automatic. Others might require changes to how the Spoke is used. Clear version management prevents confusion and breakage.

Deciding whether a Spoke is the right container

A Spoke earns its keep when the same external system or the same approval logic is needed in several places and someone has to be accountable for keeping it correct. Before packaging anything, the integration lead should ask three questions: how many processes will call this logic, who will own it when the external system changes, and whether the logic depends on data that lives only in one team’s tables. If one team is the only consumer and already owns the surrounding process, a plain flow inside that team’s scope is usually cheaper to run and easier to read. The package pays back only when reuse and ownership are both real. The Integration Hub guide covers the wider integration design choices.

Situation	Package it as a Spoke	Keep it as a flow or subflow
One external system called by several teams	Yes, so the endpoint and field mapping are changed in one place	Only if a single team will ever call it
Approval rules shared across request types	Yes, once the rules have settled and have a named owner	Yes while stakeholders are still negotiating the rules
Logic that reads a table only one team maintains	Rarely, because every consumer inherits that dependency	Yes, with the dependency written into the flow description
A one-off data correction	No	No, a scheduled job or a background script is usually a better fit

Credentials and connection aliases decide who can run the Spoke

Many Spoke failures in the first month are not logic failures. They are credential failures: the package works in the build environment, then stops after promotion because the connection it relies on was never mapped in the target. Treat the connection and credential alias as part of the Spoke’s definition rather than an afterthought. Name aliases for the role they play, not the person who created them, so a change of owner does not force a rename across every consumer.

A repeatable way to stand up a Spoke in a second environment looks like this:

1. Record every external endpoint, credential type and expected response field in the Spoke’s design note before export.
2. Create the connection alias in the target environment first, then bind a credential to it, rather than copying a credential record across.
3. Run one read-only action from the target and confirm the response shape matches what the Spoke expects.
4. Run a single write action against a disposable test record in the external system, and confirm it appears there and nowhere else.
5. Only then enable the scheduled or event-driven trigger, and watch the first batch by hand.

Failure modes that appear after the first production run

Retries are the first trap. A create action is not safe to repeat unless the external system can recognize a second identical request. Without a stable business key sent on every call, a timeout followed by a retry can produce two tickets in the other system, and it can go unnoticed until a reconciliation run weeks later. Design the write so that a repeated call with the same key returns the existing record. The idempotency and retry policy settings control that behavior, and each writing Spoke needs them reviewed before go-live.

The second trap is a silent change in the external payload. A vendor adds an optional field, renames a status value, or starts returning a list where it used to return one object. The Spoke can keep reporting success while mapping an empty value into a required field. Keep one saved sample response per action and compare it to a live response on a schedule, so a shape change is caught by a check rather than by a user.

The third trap is ownership drift. When a Spoke is copied into another scope and edited there, the original and the copy diverge, and the teams using each one assume they share the same fix. Decide which copy is authoritative and record where every other copy came from.

Telling a healthy Spoke from one that is failing quietly

Watch the outcome in the system the Spoke writes to, not only the execution history inside the platform. The execution log shows that a flow finished. It does not show that the record landed in the right state on the other side. Build one reconciliation check per Spoke: pick a small set of business keys created in the last period, query the external system for them, and count the matches. The gap that should worry you is one your service owner sets and can defend, but the habit of comparing both sides is what matters.

Also watch queue depth for asynchronous actions. When a Spoke starts to back up, the first symptom is delay rather than errors, and delay is easy to dismiss as normal load. A widening gap between when the trigger fired and when the action completed is an early signal that the connection, the mid-server or the external service is struggling. Agree which of these signals the on-call engineer acts on before go-live, and use the integration error handling approach as the reference for what to do when they appear.

Questions teams ask once a Spoke is in use

Can two Spokes call the same external system with different credentials?

Yes, and it is often the right answer when two teams need different permissions on the same system. The risk is drift. Keep one owner for the connection definition, let consumers reference it, and make an endpoint fix once.

Who should approve a change to a Spoke that other teams already use?

The Spoke owner approves, but consuming teams should see the change before promotion. A short notice listing changed inputs, outputs and failure behavior is usually enough. Any change that alters what an action returns deserves a test run from each consumer’s side.

Does a Spoke replace the need for a design note?

No. The package holds the logic but not the reason for it. A design note stating the business rule, the external system’s contract and the known limits is what lets the next engineer change the Spoke safely.

What happens to executions in flight when a Spoke is updated?

Schedule the update for a window when few executions are running, and confirm how the platform treats work that started on the earlier version. Do not assume the change applies evenly to work already in progress.

When a Spoke is the wrong answer

Avoid packaging logic whose main purpose is to get around a control. If a Spoke creates records that the normal form would reject, consumers will eventually discover that and rely on it, and the control becomes a suggestion. Avoid Spokes for workflows that change every quarter as well. The overhead of testing and versioning is worth paying for stable logic, and it becomes a drag on process design that is still moving. Where the integration itself is still undecided, the REST and SOAP guide compares the two approaches and is a sensible starting point.

Shared integrations can stall on the question of who answers for them. Write the list of consuming teams before the package exists.