ServiceNow Orchestration

Where Flow Designer and business rules act on data, orchestration uses the MID Server to execute commands securely inside your network:

The distinction that defines this whole topic is between automation inside the platform and automation that reaches out of it. A business rule, a flow updating records, an approval routing: all of that happens in the instance, and if it fails the instance knows and can retry cleanly.

Orchestration acts on something else. It restarts a service on a server, creates an account in a directory, provisions a virtual machine, calls an external API. Two properties follow and they are what make this different from ordinary workflow.

It has side effects the platform cannot undo. A record update can be reversed by updating it again. A deleted mailbox cannot.

It can succeed partially. A five step activity that completes three steps and fails the fourth has left the target system in a state that is neither before nor after, and only your design decides what happens next.

Everything in the rest of this page follows from those two sentences.

Where it runs is the other half. Anything reaching into a network the instance cannot see goes through a MID Server: an agent inside your network that polls the instance for work and executes it locally. That architecture is why orchestration works at all behind a firewall, and it also means a MID Server that is down produces work that queues rather than fails, which looks like nothing happening rather than like an error.

What a spoke gives you over writing the call yourself is worth being specific about, because it is more than convenience. The authentication is handled and the credentials live in the credential store. The actions have defined inputs and outputs, so a flow using them is readable by somebody who does not know the target system. Errors come back in a consistent shape. And when the target's API changes, the spoke is updated rather than your code.

The trade is that you get the operations the spoke exposes. When you need something it does not cover, the options are a custom action in the same framework, which keeps the surrounding structure, or a scripted call, which does not. Reach for the first before the second.

Half a day, and it teaches the part of orchestration that tutorials skip.

1. Pick something small and genuinely useful: restarting a named service on a test server, or creating an account in a test directory.
2. Build it as a flow using a spoke action, triggered from a catalog item.
3. Run it and confirm the target actually changed. Check the target system directly, not the flow status.
4. Now break it deliberately: wrong credentials, then a target that is switched off, then a valid request for something that already exists.
5. Read what each failure produces. Does the flow stop, retry, or report success. Does anybody find out.
6. Add the handling each case needs, and run all three again.

Step four is the whole exercise. Automation that works when everything is healthy is easy, and every production problem you will have is one of those three cases. See Flow Designer.

• Self-service that actually does the thing (grant access, provision, restart), not just logs a request.
• Automated remediation triggered by an Event Management alert.
• Onboarding/offboarding across multiple external systems in one flow.

What these have in common is worth noticing, because it is the test for whether something is a good candidate. Each is frequent enough that automating it saves real time, well defined enough that the steps do not change per case, and low judgement, meaning a human doing it correctly would make the same decisions every time. Something that happens twice a year, or that requires the operator to assess the situation, is not a good first candidate however tedious it is.

The other axis is blast radius. Start with things that are easy to undo, on systems that are not critical, and earn the right to automate the rest. Teams whose first orchestration project touched production directories tend not to get a second one.

Expanding on safety, because this is the part where orchestration differs from everything else in the platform.

Least privilege on the target. The credential the MID Server uses should be able to do the specific job and nothing more. An orchestration account with domain administrator rights is a very attractive thing for somebody to find, and it will be found.

An approval before anything destructive. Restarting a service in production, deleting an account, resizing a volume: these need a human decision recorded against the request, and the automation should be incapable of doing them without one.

Scope limits in the automation itself. A workflow that can act on any server will eventually act on the wrong one. Constrain it to a set, and make widening that set a deliberate change rather than a parameter somebody types.

A record of what it did. Every run should leave an audit trail naming the target, the action, the requester and the outcome, because the first question after an unexpected change is always whether automation did it.

One more, about idempotency, which matters here for the same reason it matters in integrations. An activity that is retried should not do its work twice. Creating an account is not naturally idempotent; creating an account if one does not already exist is. Building that check into the automation is what makes a retry safe, and retries will happen whether you designed for them or not.

• Over-privileged MID Server credentials.
• No approval gate on destructive actions.
• Using legacy workflow activities where an IntegrationHub spoke exists.
• No error handling, so a half-completed automation leaves systems inconsistent.

Version note: the name has moved. Orchestration was a separate product with its own activity packs, built on the classic workflow engine, and its capabilities now sit largely within IntegrationHub and Flow Designer. Existing implementations still run the old form and it is still supported, so you will meet both, and the concepts here apply to either. New work should be built in the current tooling. See business rules for the in platform half of automation, and health log analytics for a common trigger.

Building one automation takes an afternoon, and designing one that behaves sensibly when the target system does not is the judgement the course builds.