Workflows

Workflows (formerly known as Genius Workflows) are automated tasks and processes that can be run automatically or manually based on the conditions of an incident. There are endless possibilities designed to fit your exact use case. For example:

🔮 Remind Slack channel to update status page every 30 min 🔮 Automatically email legal@ whenever a SEV0 or greater occurs 🔮 Create Jira tickets on multiple project boards depending on which team is impacted 🔮 Open a Zoom or Google Meet bridge for high severity (>SEV1) incidents for high bandwidth conversations 🔮 Automatically page the Infrastructure team via PagerDuty or Opsgenie whenever the postgres-db is impacted 🔮 Use different Confluence or Google Doc postmortem templates if the incident was security related 🔮 ...thousands of other combinations to fit your exact incident process!

If you need help configuring a Workflow or don't see what you're looking for, reach out via Slack, support@rootly.io, or Intercom.

When you create a new Workflow, provide a specific name and description as you'll likely have many. This can be for a specific task you'd like to automate. We suggest creating more bite-sized Workflows scoped to specific tasks versus cramming a series of tasks into a single Workflow. This will provide more granular control of when you want them to trigger (see Step 2).

A trigger as the name states are ways a Workflow can be started. For example, incident_created will run a Workflow whenever the incident is created or severity_updated will run a Workflow whenever a severity is updated. As you can see, triggers can be broad or narrow that focus on a specific attribute of an incident.

Pick from a predefined list:

• incident_created - Whenever an incident is created via Slack, Web, or API
• incident_updated - Whenever any attribute of an incident is updated (e.g. severity, title, type, etc)
• title_updated - Whenever the title of the incident is updated
• summary_updated - Whenever the summary of the incident is updated
• status_updated - Whenever the status of the incident is updated
• severity_updated - Whenever the severity of the incident is updated
• environments_updated - Whenever the environment of the incident is updated
• incident_types_updated - Whenever the type of the incident is updated
• services_updated - Whenever the services of the incident is updated
• functionalities_updated - Whenever the functionalities of the incident is updated
• teams_updated - Whenever the team of the incident is updated
• ...we are always continuing to add more!

Depending on the type of Workflow, you may optionally choose to set the following configurations:

• Repeat Every - How frequently you'd like a Workflow to run and repeat itself. This is particularly useful for repetitive tasks during an incident such as reminders.
• Wait Before Executing (Delay) - How long you'd like to delay the Workflow from running after it has been triggered. For example, wait 36h after incident has been resolved to remind the channel to publish Postmortem.

Conditions are a specific criteria you'd like to be matched in order for a triggered Workflow to run.

Conditions are used in parallel with triggers (Step 2) and provide an additional layer of granularity.

For example, trigger (incident_created) and condition (status = started) will run a Workflow whenever the incident starts. Whereas a more narrow use case would be a trigger (severity_updated) with condition (severity = SEV 1, SEV 0) would only run when the incident was set to high severity.

Pick from a pre-defined list (multi-select available):

• Status = The status or state of the incident (e.g. Started, Mitigated, Resolved)
• Visibility = Whether or not the incident is Public or Private
• Severity = The severity of the incident (e.g. Sev0)
• Environment = The environment of the incident (e.g. Production)
• Type = The type of incident (e.g. Customer Facing)
• Service = The service associated with the incident (e.g. Stripe API)
• Functionality = The functionality associated with the incident (e.g. Login)
• Team = The team associated with the incident (e.g. Infrastructure)

After you hit create Workflow on Step 4, you'll be able to then add Tasks to the Workflow.

Tasks are steps that are run whenever the Workflow is triggered. The more integrations you have configured the more tasks you'll see. All available tasks and their how-to can be found in the documentation drop-down under Workflows.

Each Workflow also supports multiple Tasks as well.

That's it, your Workflow is configured and ready to go. We can't wait to see what you build!