> ## 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. # Retrospectives > Use retrospective processes, steps, templates, and workflows to standardize post-incident follow-up and right-size documentation across incidents. Retrospectives help teams capture what happened during an incident, identify contributing factors, and track the follow-up work needed to reduce repeat issues. In Rootly, retrospectives can be customized to right-size follow-up work based on the incident. You can define which retrospective process applies, which steps are created, when a retrospective is required or skipped, how the retrospective document is generated, and which workflows run when the retrospective is created or updated. Rootly uses the term Retrospective throughout the product, but some older workflows, variables, or integrations may still reference postmortem. Existing links and variables continue to work for backward compatibility. ## How Retrospectives Work A retrospective in Rootly is made up of several configurable parts: * **Processes** determine which retrospective flow applies to an incident * **Steps** define the work that responders complete * **Preferences** control when retrospectives are skipped or mandatory * **Templates** define the structure of the retrospective document * **Workflows** automate retrospective creation, updates, notifications, and external document generation This allows teams to right-size follow-up work based on the incident’s severity, type, team, or lifecycle phase. ## Retrospective Processes Retrospective processes define which follow-up flow should be used for an incident. Each process can be configured to apply based on: * Severity * Incident type * Team If no custom process matches, Rootly falls back to the default retrospective process. Every workspace includes a **Default Retrospective** process, which acts as the fallback and cannot be deleted. A custom process must have at least one condition to be used. If no severity, incident type, or team is attached, the process remains inactive. ## Retrospective Steps Each retrospective process contains ordered steps that guide responders through post-incident work. Steps can be configured with: * A title and description * Required or optional completion * A default owner based on an Incident Role * Due dates relative to incident resolution * Slack and email reminders Common steps include: * Gather and confirm data * Write the retrospective document * Host a retrospective meeting * Create follow-up action items * Share the finalized retrospective If your workspace uses Custom Statuses, steps can also be assigned to different retrospective phases, such as a retrospective phase and a follow-up phase. ## Skip and Mandatory Preferences Retrospective preferences control when retrospectives should be skipped or required. You can configure rules based on: * Severity * Incident type * Team This lets you make retrospectives: * **Mandatory** for high-impact incidents * **Auto-skipped** for lower-impact incidents * **Optional** when no mandatory or auto-skip rule applies By default, responders can skip a retrospective on an incident unless that retrospective is marked as mandatory. Auto-skipped retrospectives can still be resumed later using **Resume retrospective** on the incident if additional follow-up is needed. ## Retrospective Templates Retrospective templates define the content and structure of the retrospective document. Templates can be used to standardize sections such as: * Summary * Timeline * Impact * Root cause * Follow-up actions You can create and manage templates under **Retrospectives → Document Templates**. Templates support Liquid, which allows you to dynamically insert incident and retrospective data into the document. One template can also be marked as the default. Additional resources: * [Incident Variables](/liquid/incident-variables) * [Configuring Templates](/retrospectives/configuring-templates) ## Workflow Triggers and Automation Rootly supports retrospective-specific workflows that run when a retrospective is created or updated. Available triggers include: * **Retrospective Created** * **Retrospective Updated** These workflows can be used to: * Create or update the in-Rootly retrospective * Generate external documents in tools like Confluence or Google Docs * Send notifications when the retrospective changes * Apply different actions based on incident or retrospective conditions The initial retrospective is created when the incident is resolved. Retrospective workflows can then run when that retrospective is created or later updated. Older workflows may still use task names such as Create Incident Postmortem or Edit Postmortem. These names do not update automatically. To use the newer wording, edit the workflow task name or remove and re-add the task. ## Retrospective Variables In workflows, notifications, and Liquid-based templates, Rootly supports retrospective variables for linking to or referencing the retrospective. Common variables include: * `incident.retrospective_id` * `incident.retrospective_url` * `incident.retrospective_short_url` * `incident.retrospective_progress_status` Legacy equivalents are also supported: * `incident.postmortem_id` * `incident.postmortem_url` * `incident.postmortem_short_url` For new templates and workflows, use the `retrospective_*` versions where possible. Old links that use `postmortem` in the path continue to work and automatically redirect to the current retrospective URL. ## Retrospective Progress Status Retrospectives move through a progress lifecycle as responders complete the work. Common statuses include: * **Not started** * **Active** * **Completed** * **Skipped** Use `incident.retrospective_progress_status` in workflows, notifications, and Liquid-based templates to reference the current progress state of the retrospective. ## Related Pages * [Configuring Retrospective Processes](/retrospectives/configuring-retrospective-processes) * [Configuring Process Steps](/retrospectives/configuring-process-steps) * [Configuring Templates](/retrospectives/configuring-templates) ## Frequently Asked Questions A retrospective can include a process, a set of steps, a document template, workflow automation, and preference rules that determine whether the retrospective is required, optional, or skipped. Together, these settings define how post-incident follow-up is managed in Rootly. The initial retrospective is created when an incident is resolved. After that, retrospective workflows can run when the retrospective is created or updated. Rootly checks the conditions attached to custom retrospective processes and looks for matches based on severity, incident type, or team. If none match, the default retrospective process is used. Yes. By default, responders can skip a retrospective unless it is mandatory for that incident. Retrospectives can also be auto-skipped based on configured rules, and auto-skipped retrospectives can be resumed later if needed. Processes determine which retrospective flow applies to an incident. Steps define the tasks responders complete as part of that flow. Templates define the structure and content of the retrospective document itself. Some older workflows, variables, integrations, or task names may still use the older postmortem terminology. Rootly continues to support these references for backward compatibility, but new documentation and configuration should use retrospective terminology.