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
• 💅 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
• 🐛 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