> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retrospective Automation Recipes

> Use workflows to schedule the retrospective review, remind owners until it is published, and announce it when it is.

The retrospective process is where good intentions go to die: everyone agrees it matters, and it still slips, because every step needs someone to remember it. Automating the remembering is what keeps the process alive.

Recipe 1 is a setting rather than a workflow. Recipes 2 to 4 are complete worked examples, each naming a trigger, its conditions, and its actions.

***

## Recipe 1: Control Which Incidents Get a Retrospective

**Every incident already has a retrospective.** Rootly creates the document when the incident is declared, and the **Retrospective Created** workflow trigger fires when the incident is first resolved, so you do not need a workflow to create one. See [When is a retrospective created?](/retrospectives/retrospectives).

What you usually want is not *whether* it happens but *which* incidents it happens for, and that is configured under [Skip and Mandatory Preferences](/retrospectives/configuring-retrospective-processes#skip-and-mandatory-preferences), which decide whether an incident's retrospective is skipped or required. Gate by severity there. The retrospective process conditions choose which process applies, not whether there is a retrospective.

Gate on the severities your process actually requires. A retrospective created for every SEV4 produces a backlog of empty ones, which reads as a completion problem when it is really a configuration problem.

***

## Recipe 2: Schedule the Review Meeting

The step that slips most, because it needs a calendar and a quorum.

| | |
| - | - |
| **Workflow type** | Incident |
| **Trigger** | Status Updated |
| **Conditions** | `Status is: Resolved`, `Kind is: Incident`, plus your severity threshold |
| **Actions** | 1. Create a Google Calendar Event (or Create a Outlook Event)<br />2. Send Slack Message announcing it |

Fields worth setting on the calendar action:

<ParamField path="Attendees" type="list">
  Who needs to be there. The incident's responders are the obvious set; add the people whose absence would make the meeting pointless.
</ParamField>

<ParamField path="Exclude weekends" type="boolean">
  Set this. Without it, an incident resolved on a Friday evening schedules its review for Saturday, and the meeting quietly does not happen.
</ParamField>

<ParamField path="Conference type" type="string">
  Attaches a video link to the event, so nobody has to make one on the day. **Google Calendar only** — on **Create a Outlook Event**, the equivalent is the **Enable online meeting** checkbox. Set whichever your calendar action exposes; a review with no link is a review people join late.
</ParamField>

<Tip>
  Schedule the review a few days out, not the next morning. Far enough that people have slept and the logs have been read; close enough that anyone still remembers the detail. The calendar action's **Days until meeting** field sets this, and **Exclude weekends** counts only business days.
</Tip>

***

## Recipe 3: Nudge the Owner

| | |
| - | - |
| **Workflow type** | Retrospective |
| **Trigger** | Retrospective Created |
| **Conditions** | Retrospective status is `draft`, plus your severity threshold |
| **Wait** | A few days |
| **Repeat** | Every 2 days, with every day selected under **Repeat on** |
| **Stop when** | A maximum number of repeats, as a backstop |
| **Action** | Send Slack Message to the owning team |

<Warning>
  **The draft condition is what ends the nudges.** Rootly re-checks a workflow's conditions before each repeat, so once the retrospective is published, `Retrospective status is draft` stops being true and the sequence ends. Publication is the signal to watch, because retrospective progress (`completed`, `skipped`) is not available as a workflow condition.
</Warning>

Set a maximum number of repeats or a time limit as a backstop, so a retrospective that is never published does not nudge indefinitely. See [Stop Repeat Conditions](/workflows/workflow-scheduling#stop-repeat-conditions).

***

## Recipe 4: Announce Publication

The one that makes the work visible, and the cheapest of the four.

| | |
| - | - |
| **Workflow type** | Retrospective |
| **Trigger** | Status Updated |
| **Conditions** | Retrospective status is `published` |
| **Action** | Send Slack Message to an engineering-wide channel, linking the retrospective |

<Warning>
  Condition this on `published`, or the workflow also fires when a retrospective moves back to draft.
</Warning>

A retrospective nobody reads is most of the value lost. This recipe costs one workflow and is the one most likely to change behaviour, because it turns writing a retrospective into something visible rather than something filed.

***

## End to End

The four together cover the whole arc, and are worth building in this order:

<Steps>
  <Step title="Recipe 4 first">
    Announcements are the lowest risk and the highest visible value, and they tell you whether people care before you automate anything else.
  </Step>

  <Step title="Then Recipe 1">
    Set your skip preferences so retrospectives are only required where they matter. Watch the backlog for a fortnight and adjust the severity threshold before going further.
  </Step>

  <Step title="Then Recipe 2">
    Meetings are where the process converts into decisions. Automate the scheduling once you know the retrospectives are actually being created.
  </Step>

  <Step title="Recipe 3 last, if you still need it">
    If the first three are working, you may not. A nudge workflow added on top of a healthy process is the one people resent.
  </Step>
</Steps>

***

## Related Pages

<CardGroup cols={3}>
  <Card title="Retrospective Workflows" icon="gears" href="/workflows/retrospective-workflows">
    Triggers available on retrospectives and their noise characteristics.
  </Card>

  <Card title="Workflow Actions" icon="list-check" href="/workflows/actions-reference">
    Every action these recipes use.
  </Card>

  <Card title="Wait and Repeat" icon="clock" href="/workflows/workflow-scheduling">
    Delays, repeats, and stop conditions.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.