Workflows
A Workflow is an event-driven automation: when something external happens — an alert fires, a webhook is received, an SLO trips — the workflow starts an investigation and routes the result somewhere useful.
Workflows are how RunWhen connects to the systems that already exist in your stack. Your alert manager, your incident tool, your chat platform — they keep their existing role; the workflow translates an event in those systems into a RunSession and a delivered response.
Why Workflows exist
Most RunWhen activity starts with a person typing into Workspace Chat. That model breaks down in three situations:
- Off-hours alerts. No one is at a keyboard at 3 AM. By the time on-call wakes up, the diagnostic context has gone cold.
- Repetitive incident handling. Every paged alert leads the responder through the same first ten minutes — pull pods, check events, look at recent deploys.
- Cross-tool handoff. The alert lives in PagerDuty, the conversation lives in Slack, the runbook lives in Confluence, and the kubectl output lives in someone’s terminal.
A Workflow collapses those: the same event that pages the human also kicks off an automated investigation, posts the result where the human lives (Slack channel, ticket comment), and leaves a RunSession behind for review.
Trigger model
A Workflow has, conceptually, three parts:
| Part | What it answers |
|---|---|
| Trigger | What external event starts this? (Webhook, monitoring alert, SLO violation, scheduled tick.) |
| Investigation | What does the assistant do once triggered? (Open a RunSession with a chosen assistant, often invoking a Command for the standard procedure.) |
| Delivery | Where does the result go? (Slack channel, PagerDuty incident note, webhook back to the originating system, an email.) |
The trigger is the part that distinguishes Workflows from on-demand chat — everything else is the same machinery you would use interactively.
Workflows vs scheduled commands
Both Workflows and scheduled commands run automatically and deliver results, which makes them easy to confuse. The difference is purely about what fires the run:
| Trigger | Use a… |
|---|---|
| Time — “every weekday at 9 AM,” “every hour after a deploy” | Scheduled command |
| External event — “this PagerDuty alert fired,” “this webhook was received” | Workflow |
If you find yourself asking “should this be a workflow or a scheduled command?”, the question is really “is the trigger a clock or an event?” There is no overlap in the right answer.
Integration model
Workflows treat your existing tools as both inputs (triggers) and outputs (delivery surfaces):
- Slack — receive triggers (e.g., a slash command or webhook), and deliver investigations into channels or threads.
- PagerDuty / Opsgenie — trigger on incident creation, deliver context back as an incident note.
- Generic webhooks — connect to any HTTP-capable system on either side.
The platform does not try to replace your alerting or incident tooling. It adds an investigation layer that runs alongside it.
Where Workflows sit in operational maturity
Most teams adopt workflows after they have established the rest of operational context, not before:
- First, build the tasks and SLXs that produce useful Issues.
- Then layer on Rules and Knowledge so investigations read your environment correctly.
- Capture repeated investigations as Commands.
- Then wire those Commands into Workflows so external events trigger them automatically.
A workflow that fires an undertuned investigation produces noisy auto-comments on every alert — worse than no automation at all. The tasks → context → command → workflow order minimizes that risk.
Anti-patterns
- Workflows that only post raw alert text. That is what your alert manager already does; the workflow should add investigation, not relay.
- Skipping the Command layer. A workflow that hand-codes its investigation in the trigger config is hard to change and impossible to test interactively. Wrap the procedure in a Command, then have the workflow call it.
- Many overlapping workflows on the same trigger. Pick one investigation per event and let the assistant decide what to look at; multiple competing workflows produce duplicate noise.
Where to use this in the UI
For the in-product Workflow management view, see Use → Workspace Studio → Workflows. For Slack-specific delivery, see Configure → Slack Integration.