Retrospective workflows are triggered on changes to the retrospective data. Every incident created on the Rootly platform also contains a retrospective object. You can leverage the power of workflows to auto update retrospective, publish retrospectives, etc.Retrospective workflows are particularly useful for…
There are many trigger events to choose from. Check out what’s available to you on this page.In the example below, the workflow will initiate when the retrospective status changes.
Please note, because this is a retrospective workflow, the status referenced here is the status of the retrospective, NOT the incident.
Since retrospectives are tied to individual incidents, retrospective workflows can be configured to check for both retrospective and incident properties.There are two retrospective conditions available.
The cause represents the causes of the incident, which is stored against the retrospective.
Currently, cause only appears on the retrospective of an incident. There are future considerations on moving this field to align with the incident data object instead.
In the example above, the cause condition will only pass if either 3rd Party Outage or Unknown is selected for the incident cause.
As stated above, retrospective workflows can be conditioned to check for both retrospective properties AND incident properties. See the Condition Checks section for details on how incident run conditions are configured and enforced.
Available actions in retrospective workflows are dependent on the integrated applications. Actions relating to specific applications will become available once those applications are integrated.In the example below, the workflow will send a Slack message in the integrated Slack workspace.