Teams in Catalog

Modeling teams in Catalog

Understanding the teams within your organization is a key part of driving successful incident response.

We know that every organization is different, so we allow you to model teams flexibly using Catalog. For example, you could have:

• A catalog type Team that has Members, a Manager, and a Tech Lead
• A catalog type Division, which contains a list of the Teams that it includes
• A catalog type Function which has Members so you know whether someone is an Engineer, a Product Manager or a Customer Success Manager.

Once it’s in Catalog, you can use this information to drive automation across your incident response. For example, you can:

• Show or require different information when a user is declaring an incident, depending on what function they’re in
• Auto-subscribe managers to incidents that their team members are participating in
• Restrict accepting a security incident to only members of the infrastructure & security division

We’ve written a step-by-step guide to help you set up Teams in Catalog.

To whet your appetite, here are a few of the places you can use your new supercharged Team catalog type…

Incident Forms

Customise your declare incident form based on the user’s team, like defaulting the affected team to the current user’s team or showing / requiring fields based on the user. Check it out in Settings → Forms.

Workflows

Use a user’s team to build out powerful workflows. For example, auto-subscribing Engineering Managers to every incident that someone in their team is participating in. This helps keep managers aware of where members of their team might be unexpectedly spending time, and who might need support.

Restricted Incident Types

Restrict who can declare incidents of a certain type based on their team. You could restrict accepting Security incidents to users in the Infrastructure team, for example.

Managing catalog types in GitHub

Now that we’ve levelled up the Teams experience in Catalog, we wanted to ensure we have a great way for you to manage all your catalog types.

Introducing: GitHub version control for your custom catalog types. This easy-to-use flow allows you to generate all the config you need to manage catalog types in a GitHub repository containing you catalog data.

We’ll also automatically sync changes you make in the repository to Catalog, and prevent users from making changes to the types you selected through the catalog UI.

This feature builds on our existing catalog importer tool, with a heap of extra polish and functionality to make this experience feel great. If you’re already using our catalog importer and want to get the same functionality of preventing changes to certain types in the catalog UI, you can do that by following these instructions.

🚀 What else we’ve shipped

🆕 "Escalation created" timeline events are now exported to postmortems
🆕 The ID of the alert that created an incident is now included within the CSV download
🆕 You can now import OpsGenie schedules with time restrictions
🆕 You can now pause incidents until a given time in the dashboard
💅 It's now clearer when you have been paged through a workflow
💅 Our alert route form now has lots of contextual information to help you configure your incidents
💅 Our alert route form now shows a default incident preview if we haven't received an alert yet
💅 You can now bulk action pending alerts from the alerts tab in an incident in the dashboard
💅 "You're on call" notifications have been improved to be clearer about when your shift starts and ends
💅 Custom rota handover rules now have more options (1-12 hours, 1-7 days, 1-4 weeks)
💅 Scrollbars will now correctly appear underneath popovers in the alerts UI
💅 We’ve added some more information to our help centre about how Android do not disturb works
💅 We’ve made it clearer that the title and description for email alert sources are pulled from the subject and body of the email
💅 We've made it clearer which days you are creating a schedule override for
💅 New schedules now require the user to set the route name
💅 We've added more information to the incident timeline when an incident has been created by an alert
💅 Saved views are now sorted alphabetically
💅 We’ll now hide issue tracker sync failures that are more than 30 days old
💅 We’ve added a confirmation modal when deleting a catalog entry
💅 The timestamp for when you are next on-call (in the sidebar) is now relative if your next shift starts today
💅 On the alert details page, we'll now direct you to configure your alert source if you haven't configured any attributes
💅 The escalations table now handles small screens more gracefully
💅 If a triage incident is declined due to a linked alert being resolved, we now link to the alert within the Slack message
💅 We now do a much better job of sanitising whitespace and newlines from alert titles
🐛 Fixed an issue where an invalid timestamp was being displayed briefly when acking an escalation
🐛 Fixed an issue where schedules in Catalog wouldn’t update the currently on-call user immediately
🐛 You can now always dismiss the on-call upgrade modal
🐛 The sidebar QR code now hides correctly after you indicate you're not using the phone app
🐛 Fixed a bug where we'd sometimes archive a channel after the incident was un-cancelled
🐛 Incident watchers will now always be added to an incident, even if we're in the process of creating the slack channel
🐛 On-call schedules you are on will now be synced to Linear when you add a Linear connected account
🐛 Schedule entry tooltips now always show the correct start and end time
🐛 We now correctly sync user roles via SAML
🐛 You’ll now only see applicable custom fields when completing post-incident task in Slack
🐛 You’ll no longer receive incident update reminders to incidents that are paused
🐛 Workflows now render correctly in Safari
🐛 Merged incident messages with long summaries now display correctly
🐛 Assigning post-incident tasks now works as expected