Everbridge · xMatters · 2020 – 2022

Flow Designer

Drag. Drop. Done.

The people who owned an incident process could not automate it. Flow Designer let them draw it: trigger, ticket, chat channel and rollback as one flow, no code in the middle.

The Flow Designer working screen. A flow runs left to right across a dotted canvas: a Create Major Incident response opens a ServiceNow incident, creates a Slack channel, posts to it, then hits a switch that branches to a Yes path and a default path. A mini-map sits in the lower left, the step palette on the right has a search field above Triggers, Apps, Tools and Custom tabs, and an Activity panel is docked along the bottom.
A flow reads left to right, the way people say it out loud: when this happens, do these things.
Role
Lead designer — flow canvas and step palette
Platform
xMatters On-Demand
Focus
Workflow automation · No-code authoring
Users
IT operations, DevOps and SRE teams building their own toolchains

Context

An incident is never handled in one tool. Someone raises a ticket, opens a chat channel, updates the status page, rolls back the release. xMatters knew who to wake up. The rest lived in runbooks and habit.

Automating it meant writing it. Every change went through the few people who could read JavaScript.

Problem

The person who knows the process and the person who can encode it are rarely the same person. So the process stays in a document, and the gap gets filled at 3am by whoever is on call.

In the Integration Builder, one toolchain was spread across three places, each with its own kind of code.

  • Inbound. Create an endpoint, then write JavaScript to catch the POST from Jira or Splunk, pull properties out of the payload, and call XM.createEvent() to start an alert.
  • Outbound. Sending anything back — updating a ticket when someone hit Acknowledge — meant a different tab, a trigger to configure, and script blocks hand-building the POST with the xmhttp object.
  • On premises. Behind-the-firewall tools needed the Integration Agent: a runtime you hosted yourself, .js files on the server, and a command-line utility to map them to cloud rules.

Everything that was not code was a form. Branching lived in nested property tabs, so nobody could review a toolchain by looking at it — and the same actions were rewritten per customer, per tool, per team.

The Pirate Ship Workflow in the old xMatters interface with the Forms tab selected, from a row reading Forms, Flows, Properties, Integrated Properties, Integration Builder and Subscription Forms. Five forms are listed in a vertical stack; each row carries a one-line description, a dropdown selecting the channels it is deployed to, an Edit button and a delete cross. A Cherwell workflow with the Integration Builder tab selected from that same row. An Integration Services panel holds two collapsible lists: inbound integrations, which transform incoming web requests, showing two configured entries with on-off toggles; and outbound integrations, which make web requests when actions take place, showing three configured.
Two tabs every workflow had. Left, forms behind forms. Right, scripts split into inbound and outbound lists that never refer to each other. Neither says what runs in what order.
A redrawn Integration Builder inbound script editor titled Transform_CloudWatch_Alert. A single JavaScript file parses the incoming payload, filters out anything that is not an alarm, hand-maps recipients and properties, branches on a threshold with an if statement, posts to ServiceNow through the xmhttp object, and finally calls XM.createEvent. Colored bars in the gutter mark five separate jobs fused into the one file, labeled in a column to the right: trigger, recipients and payload, branching, app step and notification.
Redrawn. Everything Flow Designer would later make a separate block — the trigger, the recipients, the branch, the ServiceNow call — is one file here, readable only by the person who wrote it.

Designing the canvas

A flow should read like a sentence

Every step has an input port on the left and an output port on the right; a connector is a line between them. Direction is unambiguous, an unconnected step is visibly unfinished, and the shape on screen matches the sentence someone would say out loud.

A close-up of the canvas. Two responses on the far left, Create Major Incident and Run Remediation, feed a ServiceNow incident and an xMatters incident, which lead into a switch labeled Event Properties dot project. The switch opens three stacked paths — Antares, Deneb and a default path — and the first two each run on to Create Issue in Jira and Post to Channel in Microsoft Teams. Every step shows a small circular input port on its left and output port on its right, joined by connectors.
Paths are named with the value that selects them, not branch one and branch two. You can read which project this flow covers without opening anything.

Order without taking away control

Automatic layout places every step for you: always tidy, infuriating the moment you want two branches side by side. A free canvas becomes a tangle by the fourth step.

I took the middle: the canvas snaps to a grid. Steps go wherever you drag them; the grid keeps spacing and alignment consistent while you do it. Auto Layout stays a button — an offer, not a rule.

The port turns into a target as the step gets close. You place the step; the canvas offers the connection.

The canvas has to survive its own success

Flows that earn their keep get long, and once a canvas outgrows the window the problem is orientation, not layout. The mini-map shows the whole flow with the viewport marked on it, and doubles as the way to pan — see where you are and move in one gesture.

A pre-built SolarWinds AppOptics workflow immediately after it is installed, laid out on the flow canvas. A trigger at the top left runs into a signal-mode switch, which branches into Test, Clear and Alert paths, then into Create Alert with response steps for Acknowledge, Escalate, Close and Initiate Incident hanging below it, and a second branch that checks for active events and terminates them. The flow runs past the bottom of the window; a mini-map in the bottom-left corner shows the whole shape with the current viewport marked.
A pre-built workflow, one second after install. This is the size real flows reach.

Designing the palette

Breadth is the product; findability is the design problem

The promise is that your tools are already in there. That argues for a large palette, and a large palette argues against browsing. Curating to a short list of popular steps would have made the palette calmer and the product smaller.

So it keeps everything and gets two ways in. Tabs group steps by kind — triggers, apps, tools, custom — for the person orienting; search filters by keyword for the person who already knows the tool’s name. Browsing is for learning the system; search is for using it.

The four palette tabs side by side. Triggers lists utility triggers, incident triggers and app triggers such as AppDynamics Events and AWS CloudWatch Alarms. Apps lists vendors alphabetically from Everbridge to Moogsoft, with Microsoft Teams expanded to show its steps. Tools lists utilities — merge, switch, webhook — above a long run of xMatters actions. Custom is filtered by Owned, Shared With Me and All, and its steps carry in-development badges.
Custom steps get their own scope filters — owned, shared with me, all — and carry in-development badges.

Custom steps are first-class

A no-code tool that punishes you for hitting its edges is a demo. A step a team built for their own proprietary system sits in the palette beside the built-in apps, drags out the same way, connects with the same ports. Code goes into the step, not into the flow — the Integration Builder did not disappear, it moved inside the node.

Tradeoffs I made

Snapped the canvas to a grid instead of laying flows out automatically.

Automatic layout guarantees a tidy canvas. It also makes every flow look the way the tool thinks, not the way the team thinks.

What I gave up: the guarantee — a determined person can still make a mess. What I got: authorship. Flows get arranged the way the team reasons about the process, and the grid keeps that legible to whoever opens it next.

Kept the whole step library in the palette instead of curating it.

A short, opinionated palette is easier to design and easier to demo. It also quietly tells anyone whose tool is not on the list that the product is not really for them.

What I gave up: a palette you can take in at a glance. What I got: the promise the product actually makes — your toolchain, not our shortlist — paid for with tabs and search.

What teams build with it

Three patterns account for most of what gets drawn.

  • IT Ops. Flows that let delivery move fast without dropping the compliance, performance and reliability commitments underneath it.
  • DevOps and SRE. Rolling back a release or shipping a hotfix runs the same way every time, not the way the person on call remembers it.
  • Major incident management. The MIM runbook executed as written. The gap between a process on paper and the same process at 3am is where escalations get lost.

Outcome

Flow Designer became how toolchains are built in xMatters; the Integration Builder became the thing it migrates away from. Extracting variables and formatting a REST payload back to ServiceNow — dozens of lines of JavaScript across two tabs — became an app step dropped onto the grid.

What that buys: a team follows a predefined remediation path instead of improvising one, and the unplanned work that used to fill an incident stops being done by hand.

The public evidence is sentiment, not internal numbers. Reviewers name workflow customization as the platform’s strength — “incredible customization when creating workflows, making it extremely versatile” — and Sky’s principal technical specialist: automating incident escalation “gives our teams more time to focus on resolution.”

What I’d change

The canvas made building visible. Configuration stayed behind it. The same reviews that praise the flexibility say the complexity “can make it difficult at times to get things configured properly,” and that finding the script on a step takes several clicks — a fair description of a surface I helped draw.

I would make a step’s configured state readable from the canvas, so a flow shows its substance and not just its shape. Drawing the process was the easy half.