How to get integrated

In xMatters, creating an integration (or tailoring an existing integration) to suit your particular needs is as easy as 1-2-3. The overall steps are the same whether you want to customize the information gathered from the source application and sent with the notification from xMatters or you want to link one application to the next in a powerful, automated incident resolution process.

Of course, if you want a plug-and-play integration with one application, we have a bunch of integrations built into xMatters that only require basic setup to get started. And you can ignore everything below...until you decide you need to tweak things just a little.

1. Make a plan

The first thing you need is a communication plan. The plan defines the framework for related events, things such as message templates, available event properties, possible response options, and what happens when something changes. It also controls permissions and how you can kick off an event (for example, from the Messaging tab in the user interface, from a form in the mobile app, or programmatically from an integration).

There are a few ways you can get a communication plan: convert one of our built-in integrations, install one of our packaged integrations, or create your own from scratch (or even try an experimental xM Labs integration if you're feeling adventurous).

Once you have a plan, you can customize it. Some of the alterations you might want to make are:

  • Changing which properties are brought into xMatters from the source system, which ones are available to use in a particular form, and which ones are sent in any messages from the integration.
  • Editing the content and appearance of messages that are sent (for example, putting things in a table or matching your company's branding).
  • Customizing response choices.

2. Inject information into xMatters

Inbound integrations are primarily used to create an event in xMatters. They're the part of the communication plan that processes the request from the source application and parses the information coming in.

You can set them up to simply trigger the event and send the notification defined in the form builder, or you can configure the inbound integration to parse and modify the incoming data, enrich it using additional web requests, and finally create an event to send notifications.

Use the Integration Builder to add or edit inbound integrations. If you want to see how it's done, check out our example.

3. Trigger the next steps

Finally, if you want to truly unlock the power of an automated toolchain to facilitate your digital services availability and incident resolution processes — while still using the tools you already use every day — you can design a flow in Flow Designer. In Flow Designer, you add a trigger to kick off a series of actions across different tools, drop in ready-made steps for each of those actions, and connect the steps to set up how key incident resolution information is passed from one step to the next, and even into other applications.

Example, please!

You could set up a response option (say, "Start Major Incident Management") and use the Responses trigger, so when the on-call resource selects "Start MIM", an issue is created in your ITSM application, including information from the application monitoring tool and the event information from xMatters; a channel is created in your chat tool using the ITSM incident number in the name, so your team can collaborate on resolving the issue quickly; and a status website is updated if the issue is customer impacting. All from your on-call resource selecting a single response in the notification from xMatters.

You can use the following changes to trigger flows:

  • Event status updates: the event is started, suspended, resumed, or terminated.
  • Event comments: a user adds a comment from the mobile app, xMatters Inbox, email, Tracking Report, or xMatters REST API.
  • Escalations: an escalation occurs in a group.
  • Device delivery updates: a notification is delivered to a device, or notification delivery fails.
  • Notification responses: a user responds to a message.
  • Targeted recipient failures: none of the targeted recipients could be immediately notified for an event.

We go into detail on each of these triggers in Flow triggers, where you can see examples of when you might use each on and what information is passed along by each, or you can check out our ready-made steps.

4. Go further

But you said it was easy as 1-2-3? It is, and if you stop here you've still unlocked the power of integrating with xMatters. But there's more you can do if you want to.

After you have an integration initiating events and triggering flows, we provide you with the toolkit to tailor this to your unique workflows.

What does that mean in the real world?

Here's an example:

Say you have a custom built monitoring tool that you want to initiate events in xMatters... we won't have an integration with that tool, but you can use our Integration Builder to create one. Or maybe you're required to flag any events injected by said tool that have "blueberry" in the summary and send them to a special project in a service desk application — you can use a custom step in Flow Designer to search for blueberry and decide what next step to take based on whether it's there or not.