Convert an inbound integration to a flow

You've probably noticed some changes to your communication plans and integrations recently — for example, communication plans evolving into workflows and things flagged as deprecated.

And you might have some questions, like "Why am I seeing 'deprecated' tags?", "are things going to stop working?", and "what's happened to my inbound integrations?".

Of course, you might already have heard about the power of Flow Designer and want to jump in converting your Integration Builder integrations to flows. If so, you can skip ahead.

What's happening...and why?

We've been hard at work turning our integration platform into an easy drag-and-drop interface that anyone — coders and layfolk alike — can use to connect their everyday tools into a seamless, automated incident resolution chain. Maybe you've already started building flows in Flow Designer, the first phase of this transformation.

As part of that effort, we recognized we can do a better job of bringing the tools for managing and executing all your integrations into one place. We want to make it easy for you to not just integrate, but to build your incident management workflows.

What do I need to do? Will things stop working?

Don't worry, integrations built using the Integration Builder will continue to function, though there are some minor changes to how you work with them. If that changes, we'll give you lots of warning. However, as we work to make sure Flow Designer has all the functionality of the Integration Builder and more, you'll see those deprecated flags pop up in a few places as we turn on new features and capabilities. It lets you know there's a different — and we think better — way of doing things, and you might want to convert your inbound and outbound integrations into flows to take advantage of that.

So, at the moment, you don't need to do anything. But, if you want to unlock the power of Flow Designer and explore a new way of thinking about incident management workflows, you can convert your integrations to flows.

Why should I convert my integrations to flows?

We recognize that your integrations are probably working for you, otherwise you wouldn't be using them. But Flow Designer opens up a whole new way of thinking about your incident resolution workflows.

Converting your integrations to flows and flow steps lets you share that power across your organization, including with people who might not be as comfortable with code. Even if you're a coder, there are benefits for you as well — did anyone say observability?

Converting integrations to flows lets you:

  • kick off a whole series of actions, all without manual intervention. Even without initiating an xMatters event if that suits your processes the best.
  • break big blocks of code into discrete steps, reusable by anyone in your organization whether they're coders or not...if you decide to let them.
  • change a step in one place and have that update available wherever the step is used, making it easier to adapt to the ever-changing world.
  • share steps across your organization to drive consistency and repeatability in your incident resolution processes.
  • pull information from your tools and make it available to other steps in the flow, including using it to make decisions about what steps the flow should take next.
  • see at a glance exactly which step is having problems if something goes wrong.

Okay, I'm sold...now what?

There are two components to converting your inbound integration to a flow:

  • Creating a basic flow with a trigger to receive the request and a step to create an event.
  • Reviewing your integration script to see what steps might be buried in there.

Create a basic trigger + event flow

First, we'll create a simple two-step flow consisting of a trigger plus a create event step. This gets the basic functionality of the integration into Flow Designer. If all you want to do is to send a request from your third-party application and launch an event, you can stop after completing these first two steps — of course, then you'll miss out on a lot of the cool features Flow Designer offers.

Fully convert your integration into a flow

To convert your integration to a fully fleshed out flow, there's an additional step — reviewing the integration script to see what steps are hidden inside.

You can pack a lot of functionality into a block of code but when it's hidden in the Integration Builder script, it's hard to reuse, re-purpose, build on, or troubleshoot if something goes wrong, especially if you're not a coder.

And there's a good chance you can replace a lot of that code with built-in steps. To do that, we need to take a step back.

Okay, I've examined my script...now what?

The first two steps are the same as the trigger + event option: create an HTTP trigger and add a create event step to your flow. However, we need to add a few steps in there.

Take it a step further

Once you've turned your integration into a flow, it's easy to add additional steps to your flow, whether you go with the option to build a simple, two-step flow or completely convert you script into a flow. Heck, even if you don't convert your integration to a flow, you can still add steps to the legacy integration.

For example, you could:

  • Use one of our built-in apps to update a record in another system with xMatters event information or change the status of a ticket based on the user's response.
  • Create a custom step to post incident information from steps all along the flow to your proprietary dashboard.
  • Use a switch step to only create an event in certain circumstances.
  • Tweak the notification sent to the assignee, for example, adding a new response choice that initiates a flow of its own.

What if I'm happy as is?

That's okay. We understand that you've got a system that works for you. As mentioned, we'll let you know if a change comes along that will impact your existing integrations. There are some changes with how you work with legacy integrations in Flow Designer.

Can I see an example?

Absolutely. Below, we'll walk through each of the steps using the example of converting a "Notify Assignee" inbound integration to a flow. The integration was designed to notify a user in xMatters that they've been assigned to a service desk ticket after finding and terminating any existing events related to the ticket.

That's it. We've turned that blob of code into a flow of discrete, reusable, and observable steps.