Everbridge · xMatters

Flow Designer

From scripts to visual workflows.

Incident automation required JavaScript, so the people who managed incidents had to rely on developers to build their workflows. I led design for Flow Designer, a visual builder that let incident teams create those automations themselves by connecting triggers, actions, and integrations on a canvas.

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.
The workflow runs left to right, with each step connected to the next.
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

Incident management involves more than responding to an alert. Teams often need to automate what happens next: create a ticket, notify people, update another system, open a chat channel, or trigger a remediation action.

Before Flow Designer, xMatters users had to write JavaScript to connect these steps. The people managing incidents could define the process, but they needed developers to build and maintain the automation.

Problem

Incident teams had to rely on developers to automate their workflows.

Automating a workflow required JavaScript. A simple workflow could involve code for receiving an event, extracting data from its payload, sending information to another system, and deciding what should happen next.

  • Inbound. An integration required an endpoint and JavaScript to receive a request from Jira or Splunk, extract properties from the payload, and call XM.createEvent() to start an alert.
  • Outbound. Updating another system, such as changing a ticket when someone acknowledged an alert, required a separate trigger and JavaScript to build the request.
  • On premises. Connecting tools behind the firewall required the Integration Agent, JavaScript files on a server, and a command-line utility to connect them to cloud rules.

Everything outside the code was configured through forms. Branching was buried in property tabs, and the different parts of a workflow were spread across separate screens. There was no single place to see how the workflow worked from beginning to end.

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.
The old workflow was split across forms and separate inbound and outbound integrations. There was no single view of how the workflow ran.
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.
A single JavaScript file handled the trigger, data mapping, branching, ServiceNow request, and notification. Flow Designer separated these into individual steps.

Approach

Designing the canvas

A flow should read from left to right

Each step has an input port on the left and an output port on the right. Connectors show how one step leads to the next.

The direction is consistent across the canvas, so the workflow can be read from left to right: when this happens, do these things.

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.
Each branch is labeled with the value that selects it, so the logic is visible on the canvas.

Users can place steps where they want

Automatic layout keeps a workflow tidy, but it also decides where every step goes. A free-form canvas gives users control, but becomes difficult to keep organized as workflows grow.

I used a grid to provide structure without controlling the layout. Users can place steps where they want, while the grid keeps spacing and alignment consistent. Auto Layout is available when users want it, but it is not required.

Dragging a step near an existing connection point highlights where it can be connected.

Long workflows need navigation

As workflows grow, they can become much larger than the visible canvas. At that point, users need to know where they are and move around the workflow quickly.

The mini-map shows the entire workflow and marks the current viewport. Users can also use it to pan around the canvas.

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 showing how large a flow can become as more steps and branches are added.

Designing the palette

The palette needs to support many tools

The value of Flow Designer depends on the tools users can connect to. The palette therefore needs to support a large number of triggers, apps, tools, and custom steps.

I kept the full library available and provided two ways to find a step. Tabs group steps by type for users who want to browse. Search lets users find a specific tool when they already know what they need.

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.
The palette organizes steps into Triggers, Apps, Tools, and Custom, with filters for custom steps.

Users can add their own steps

Users also need to connect systems that are specific to their organization. Custom steps appear in the same palette as built-in steps and work the same way on the canvas.

Users can build the underlying integration with code, but the code stays inside the step. The workflow itself is assembled visually.

Outcome

Flow Designer replaced much of the JavaScript-based workflow setup with visual steps that users could place and connect on a canvas.

For example, work that previously required dozens of lines of JavaScript across multiple tabs to extract variables and format a REST request to ServiceNow could instead be represented by an app step on the canvas.

The resulting workflow also makes the runbook visible. Teams can see the sequence of actions and build the workflow so the same remediation process runs consistently.

  • IT Ops. Automate operational processes while keeping the required compliance, performance, and reliability steps in place.
  • DevOps and SRE. Automate actions such as rolling back a release or shipping a hotfix so they run consistently.
  • Major incident management. Turn a documented MIM runbook into an executable workflow.