> ## 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 an Outlook Event) 2. Send Slack Message announcing it | Fields worth setting on the calendar action: **Attendees** `list` Who needs to be there. The incident's responders are the obvious set; add the people whose absence would make the meeting pointless. **Exclude weekends** `boolean` Set this. Without it, an incident resolved on a Friday evening schedules its review for Saturday, and the meeting quietly does not happen. **Conference type** `string` Attaches a video link to the event, so nobody has to make one on the day. **Google Calendar only** — on **Create an 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. > [!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. *** ## 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. 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. 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: **1. 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. **2. 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. **3. Then Recipe 2** Meetings are where the process converts into decisions. Automate the scheduling once you know the retrospectives are actually being created. **4. 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. *** ## Related Pages > **[Retrospective Workflows](/workflows/retrospective-workflows)** > > Triggers available on retrospectives and their noise characteristics. > **[Workflow Actions](/workflows/actions-reference)** > > Every action these recipes use. > **[Wait and Repeat](/workflows/workflow-scheduling)** > > Delays, repeats, and stop conditions. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.