Configure your debriefs

Declare who should be invited to your debrief

Sometimes you might want to schedule a debrief meeting after your incident has been resolved, to regroup and discuss what happened. We already help by pre-filling a Google calendar event with important information, but you can now decide which users should be invited to that event.

For example, you might want the incident responders to always be invited, but additionally include senior leadership if it’s a critical incident. You can make this as complex as you like with the power of expressions, for example we can invite engineering@incident.io if the incident is one type, or customersuccess@incident.io if it’s another.

Create policies for debriefs

We already let you define policies about your follow-ups and post-mortems, and we’re now extending this to debriefs. If it’s crucial that your critical incidents always invite senior leadership, or that the debrief is scheduled a certain number of days after the incident is resolved, you can now bake that logic in to your configuration. If a debrief violates your policy, we can let the debrief organizer know that they need to update the event.

Find incidents with a debrief

It’s now possible to filter the incidents that have a debrief, by choosing “Has debrief” from the incidents list page. If this is an important view for you, you can always hit “Save view” to make it available to everyone in your organisation.

🚀 What else we’ve shipped

💅 Improve the spacing and layout in incident lifecycle settings

Improvements

Start rendering buttons to create/edit/delete catalog types nicely when the user doesn’t have permissions to manage catalog types
Stop sending updates to incident subscriptions for transitions between learning statuses
Incident dashboard tabs only default to "Learning" tab while learning flow tasks are incomplete
When attempting to resolve an incident that is already resolved, we will now notify you via an ephemeral message
We now display the name of the catalog type in catalog-backed custom field settings page
We’ve enabled using expressions as condition parameters e.g. Incident Reporter is one of {Expression}
Use more consistent language in workflow triggers
Center brand logos on Status Pages unsubscribe page
Enable deleting a workflow from the edit Workflow page
You’ll now see a bigger selection of the Slack users in your workspace when building workflow steps like “Invite user”
Make the side drawers animate more smoothly in the new Workflows page

Bug fixes

Slack messages exceeding the Slack character limit were not being posted
When removing an item from a multi-select dropdown, all selected items were accidentally removed
We’ve fixed a bug where the summary would not update on the incident details page
When using a variable with multiple Slack users in a message, we used to tag only one person repeatedly, rather than tagging everyone in the list
When filtering an expression that starts from 'all catalog entries of a type', a 'filter' step didn't let you filter on attributes of those catalog entries
Skipping "Create post-mortem" tasks in the learning flow should no longer skip the "Schedule a debrief" task
Custom fields not backed by the catalog accidentally appeared to be unset when evaluating incident conditions
When creating a status page maintenance incident, we won’t set an automatic status if the maintenance has already occurred
Handle race condition which sends duplicate learning status messages
We’ll now correctly list options for a Jira multi-select field when exporting a follow-up to Jira via Slack
Rich text expressions inside templated text fields were not displaying correctly
Conditions language for boolean logic operators showed 'and' instead of 'or'
Validation was not applied correctly in workflow conditions
Default workflow frequency was not being set on new workflows