Flow Designer

Context

Incident response varies by alert and runbook. A response might involve creating a ticket, notifying people, updating another system, opening a chat channel, or triggering remediation.

IT Ops and SRE teams need to turn their operational knowledge into repeatable, reliable automations.

Problem

Automation was code-dependent, hard to understand, and fragmented.

Automation logic was implemented in JavaScript, so people who owned incident processes relied on developers to build or change automations.

Building a workflow also meant working across two separate tools: Forms and Integration Builder.

The result was a fragmented, code-dependent process that made workflows harder to build, understand, and maintain.

The challenge

Make incident automation accessible to the teams who own incident response, with a single place to understand, build, and share workflows without writing code.

My approach

• Understand the logic: Map existing scripts to the components and behaviors a workflow needs.
• Make logic visible: Explore a canvas model that represents workflows as connected, reusable steps.
• Support flexibility: Design ways to combine triggers, flow controls, integrations, and custom tools.

Understand the logic

I mapped existing automation scripts to identify the steps, data, and connections a visual workflow would need to represent:

• Inbound: Receiving requests from Jira or Splunk required an endpoint and JavaScript to extract properties from the payload and call XM.createEvent() to create an event that initiates an alert.
• Outbound: Updating another system, such as changing a ticket when an alert was acknowledged, required a separate trigger and JavaScript to construct the request.
• On-premises: Connecting tools behind a firewall required the Integration Agent, server-side JavaScript files, and a command-line utility to connect those tools to cloud-based rules.

Across these scenarios, I identified the core building blocks of a workflow:

• Trigger: the event that starts a workflow
• Payload: the data associated with the triggering event
• Branching: the paths of a workflow based on conditions or decisions
• App step: an action performed within the workflow
• Notification: a message sent to users or systems

Explore a visual model

I explored a canvas model that:

• made workflow logic visible,
• represented triggers, decisions, and actions as steps,
• let users connect steps to define workflow.

Explore flexibility and customization

Incident workflows vary across teams, tools, and operational scenarios. I explored ways to:

• expand the ranges of available triggers and actions,
• support more complex branching logic,
• let users define and share custom tools.

Flow Designer

The key shift: from writing automation in code to designing workflows visually.

With Flow Designer, teams can create workflows by connecting triggers, decisions, and actions on a single canvas.

Outcome

Flow Designer replaced much of the JavaScript-based setup with a visual workflow builder, enabling incident teams to create automations by connecting steps on a canvas.

For example, extracting variables and formatting a REST request to ServiceNow previously required JavaScript across multiple tabs. With Flow Designer, users could configure this logic through an app step on the canvas.

Making workflow logic visible also helped teams inspect runbooks and configure repeatable remediation processes more easily.

• IT Ops: Automate operational processes while preserving compliance, performance, and reliability requirements.
• DevOps and SRE: Automate actions such as rolling back a release or deploying a hotfix through consistent, repeatable workflows.
• Major incident management (MIM): Turn MIM runbooks into executable workflows.