Incident Resolution

We're officially releasing xMatters Incident Management to all customers in our Joust Quarterly Release (Oct/Nov 2020). If you're enrolled in the Early Access Program and want to try out this feature before then, reach out to Customer Support to have it enabled in your non-production environment.

The Incident Resolution workflow is an installable workflow template designed to help you tailor xMatters Incident Management to your incident resolution process. It starts as the same workflow used by default for the Incident Management feature, but lets you adapt how incidents are created, what happens when they're created, and the notifications that are sent to resolvers when the incident is initiated.

This customizable workflow lets you:

  • add collaboration channels to incidents.
  • include automated steps in the incident resolution flow to create incidents or send incident information to other systems.
  • customize the settings for new incidents.
  • tailor notifications sent about the incident when it is initiated, including information from other tools that might help resolvers triage and address the issue.
  • allow your team or your tools to initiate incidents using email or an HTTP trigger.
  • control who can initiate incidents with the workflow.

For more information on initiating and working incidents, see our help on the Incidents list and Incident Console.

How to use the workflow

After you install the workflow, anyone you give sender permissions to can use it to initiate incidents from the Initiate Incident button or widget. They just need to look for the workflow name and select the flow trigger form:

A dialog box appears where they can fill in the incident details:

Learn more in our topic on initiating incidents in the web user interface, or learn about changing the trigger for automatic incident initiation.

Configure the default workflow

The default workflow functions the same as the xMatters Incident Management workflow, but allows you to make customizations.

The workflow includes two forms: a messaging form to notify resolvers about new incidents and a flow trigger form that lets you initiate an incident by submitting the form. Customize the form associated with the create event step (the New Incident Notification form) to modify the notification that are sent to resolvers when the incident is initiated. The only modifications you can make to the flow trigger form are whether it's enabled and who has permission to use it.

The workflow also has three flow canvases — the Trigger an Incident canvas contains the flow that initiates incidents. That flow has three steps:

The following sections walk through the changes you can make to each of those steps. Depending on your incident resolution process, you might do one, some, or all of the steps below. For instructions on adding collaboration channels, see the following instructions dedicated to that.

Since it's always a good idea to test what you develop, initiate a test incident after you make changes to the workflow to check that the incident that gets created meets the needs of your incident resolution framework.

Add collaboration channels

One of the most common — and most useful — additions to the basic workflow is to automatically create collaboration channels when you initiate an incident.

Communication amongst your team and with stakeholders is key to resolving an incident efficiently and preventing similar incidents from happening in future. But setting up collaboration channels can easily fall through the cracks when you're dumped in the middle of an incident.

By adding steps to the initiate incident flow, the channels that suit your incident resolution framework get created and associated with the incident automatically. For example, you can create separate chats with different purposes (such as one for cross-team communication, one for the Ops team, and one for the team communicating about the issue to customers) or create different channels depending on the severity of the incident (critical incidents get all the channels while medium ones just get a single chat).

If you add additional steps to enrich and automate the resolution process, you can feed information from those steps into chat channels.

Add collaboration channels to an incident resolution workflow

To add a collaboration channel to an incident, add and configure the step in the associated flow in Flow Designer: Slack Create Channel, Teams Create Channel or Create xMatters Conference.

Since it's always a good idea to test what you develop, initiate a test incident after you've added your collaboration channels to make sure they get created and appear in the Collaboration section in the Incident Console.

Automate and enrich

Collaboration steps aren't the only steps you can add to the flow — the flexibility of Flow Designer lets you connect to all the tools in your toolchain to automate resolution and enrich incident notifications.

Change the trigger

If you want to initiate incidents in ways that don't require users to fill in a form, you can change the trigger for the flow, allowing the workflow to initiate an incident by HTTP trigger or email, or when a user selects a specific response to a notification.

  • Swap out the form trigger for an HTTP trigger to automatically initiate an incident when xMatters receives an alert.
  • Use an Email trigger to initiate incidents via an email to xMatters.
  • Connect the Initiate Incident step to a Response trigger to let your people create an incident at the touch of a button.

Add additional steps to gather information from or take action in other systems

Some steps you might add before the Initiate Incident step are:

  • Create issues in other systems such as Jira or ServiceNow and add that information to the incident summary or description.
  • Set the Incident ID or severity to match a value passed in from another system. For example, you can drag the issue ID or incident ID output from a create issue step into the Incident ID field in the Initiate Incident step.
  • Run a playbook or rebuild a Jenkins job, and then use a switch step to only create the incident if that didn't solve the problem.

After the Initiate Incident step, you could add steps to:

  • Update issues in other systems. For example, add a comment to that Jira or ServiceNow issue you created before the initiate incident step to update playbooks with any lessons learned from the incident.
  • Update records in the signal source. For example, if the incident was created because of an incident in ServiceNow, you can update the ServiceNow record with information about the xMatters incident.
  • Post a message to a status page to let people know you're aware of the issue and are working on it.