Workflows & automation

Workflows automate repetitive tasks that are triggered by events in Batida. Instead of manually notifying a team, updating a status page, or escalating an incident, you define a workflow that does it for you.

Why automate

Incident response involves many repetitive steps: notifying on-call engineers, updating Slack channels, escalating to management, posting to status pages. Workflows eliminate manual effort and ensure consistency -- every incident gets the same high-quality response.

How workflows work

A workflow has two parts:

1. Trigger -- the event that starts the workflow (e.g., "incident declared as P1").
2. Steps -- the actions the workflow performs in sequence (e.g., "send Slack notification," "create Jira ticket," "escalate to VP").

Trigger fires (e.g., P1 incident declared)
       |
       v
Step 1: Notify on-call via PagerDuty
       |
       v
Step 2: Post to #incidents Slack channel
       |
       v
Step 3: Update status page component to "Major Outage"
       |
       v
Workflow complete

Steps can run sequentially or in parallel. Conditional logic lets you branch based on incident properties like severity, type, or affected team.

Workflow states

State	Description
Active	The workflow is enabled and will run when triggered
Paused	The workflow is temporarily disabled
Draft	The workflow is still being configured
Archived	The workflow is no longer in use

Where to go next

• Creating workflows -- build a workflow from scratch or from a template.
• Triggers -- understand the events that can start a workflow.
• Steps & actions -- define the actions your workflow performs.
• Templates -- use built-in workflow templates for common automations.