Workflows: your process, automated

After many weeks of work, we're delighted to announce the latest feature of the incident.io platform: Workflows. Configure your processes once, and we'll make sure you follow them, every time ✨

A little while ago, I was asked the question: “what makes a good incident response?”. Whilst there’s infinite nuance in the answer, mine was pretty straightforward. The best incidents are founded on principles of communication, coordination, and clear roles and responsibilities.

But principles alone aren’t enough; organizations are left to figure out how to follow them, often wasting time repeating the same work of writing their own custom tooling, or documenting their processes on paper.

This is why we started incident.io. We believe this set of principles can be encoded and implemented for all organizations, bringing sensible defaults and simple customisations to everyone so they can respond effectively when things go wrong.

Equally, we’re very aware that every organization is different. Different people, products and organizational structures place different demands on how you deal with incidents, and we want to support that. This is why we built Workflows.

Workflows provide an extension point to the product, allowing you to configure your specific business processes and requirements into incident.io, giving you confidence that they’ll be followed in the heat of the moment.

Need a set of actions to be picked up when an incident is tagged as a data breach? Want to escalate to a specific team when a particular product is impacted? As of today, this is possible with incident.io.

We’re building with opinions and (a hint of) flexibility

We often think about the features we build on a spectrum of flexibility. With increased flexibility comes a great deal of power, but at a cost of complexity.

Think about Microsoft Word: there’s literally hundreds of knobs and dials to customise your documents, but for many this is confusing. Now think about a tool like Notion. It has strong opinions about how documents should be laid out, and gives you very little ability to change that. If that fits your way of working, it’s a far greater (and simpler) experience.

At incident.io, we’re not building a flexible generic incident framework; we’re building an opinionated and simple product to bring best-in-class incident response to everyone.

As Mark Twain once wrote: “I didn't have time to write you a short letter, so I wrote you a long one.” We deeply understand incident response and we’ve taken the time to make it simple and accessible. By deploying incident.io, you’re importing years of experience, well tested processes, and sensible defaults.

All that’s been missing is the flexibility to fully imprint your process on top, and that changes today!

Workflows encode your repeatable processes

All incidents are unique, and by definition a break from expected or ‘normal’ work. Because of this, you’ll often find yourself dealing with unfamiliar situations and needing to improvise under pressure.

But underneath the complexity and unfamiliarity is a process. The same process. A repeatable process. Our goal is to take all of the repeatable processes off your plate, so you can focus on the most highly leveraged activities that matter most.

If it can be written in a document, it’s a repeatable process, and it shouldn’t be something you have to do; it should be a Workflow.

Workflows allow you to automate certain actions and behaviours based on specific triggers. We provide a set of building blocks which you can put together to encode your organization's processes into incident.io.

Practical applications of Workflows in the wild

Enough talk, what can you actually do with a Workflow?

Taking the pain out of paging

As a customer support agent I want to be able to raise the alarm, but I have no idea who to escalate to.

Way back in February, we announced our shiny new integration with PagerDuty. Instead of leaving Slack, logging into PagerDuty and trying to remember how to page someone, we made it possible for you to escalate with a single /incident escalate command. What we’ve missed until now is the ability to automatically escalate to a person or team.

We want to make incidents accessible to everyone in an organization – a view that we share with many of our customers. We’ve been asked many times to make it simpler for customer support and other non-technical folks to declare incidents and be confident they’ll reach the right people without further intervention.

With workflows, we can automatically escalate on incident creation, optionally routing to different teams depending on the type of incident. Simply report with /incident, and we’ll take care of getting the right people in the room ​​✨

Building bespoke runbooks

As an Engineering Leader, I want to make sure we follow a defined process when failing over our database.

Incident actions have been a core part of the product since the very beginning. They’re a lightweight way to share what needs to be done, and ensure work is clearly tracked and assigned to owners.

It’s simple to create one with /incident action, but what if we want a set of default actions to complete in all incidents, or a specific set of actions based on different incident types? Previously that’d be something for you to write down in a process doc or runbook. Now, it’s possible with runbooks.

Consider an established process for a database failover. Tag an incident as such, and your workflow can both post a message explaining what’s happening, and create the actions so people can assign themselves to them.

Listening for the keywords in your key words

As the Data Privacy Officer, it's my responsibility to ensure we report incidents correctly. I can't be in every incident, and I want confidence the right things will happen when I'm not there.

Earlier this year we released Decision Flows, which allow you to configure question and answer sequences that can be followed in the heat of an incident to aid decision making. For example if you suspect a data breach might have occured, you might want to determine whether it’s externally reportable.

What’s been missing is an automatic and contextually relevant trigger, with companies instead having to remember to use it. Clearly not something that works repeatably under pressure.

With workflows, you can configure a Decision Flow to appear in a channel when an incident is tagged to a certain type, or on mention of a specific word or phrase. Now when someone says “data breach” or “report to the ICO” you can automatically suggest they follow a Decision Flow to figure out what to do.

We’ve spent a lot of time building this feature so it’s scalable and we can iterate quickly on extending it. How it’s built is a whole blog post in itself (and one that’ll follow soon!) but we’re so confident in our ability to ship quickly, we’d love your feedback on new triggers or steps you’d like to see. Challenge us!

If you'd like to find out more, try creating a workflow or read our docs.