Convert an inbound integration to a flow

We've been hard at work turning Flow Designer into an easy drag-and-drop integration platform that anyone — coders and layfolk alike — can use to connect their everyday tools into a seamless, automated incident resolution chain.

We recognize that you might have Integration Builder integrations that are working for you, otherwise you wouldn't be using them. You don't need to convert your integration to a flow — it'll continue to function as it did before. 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?

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 someone say observability?

Converting integrations to flows lets you:

  • kick off a whole series of actions, all without manual intervention. Even without initiating an xMatters alert 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?

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. 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 alert.
  • Reviewing your integration script to see what steps might be buried in there.

Actually, what if I'm happy as is?

That's okay. We understand that you've got a system that works for you. We'll let you know if a change comes along that will impact your existing integrations. If you want to work with these integrations in Flow Designer, instead of the Integration Builder, there are some things you should know.

Create a basic trigger + alert flow

First, we'll create a simple two-step flow consisting of a trigger plus a Create Alert 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 alert, 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.

Want a head start? Use our Send Alert workflow as a starting point, and edit the HTTP trigger to add any important information from the payload into the outputs.

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 + alert option: create an HTTP trigger and add a create alert 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 your script into a flow. Heck, even if you don't convert your integration to a flow, you can still add steps to the inbound integration trigger.

For example, you could:

  • Use one of our built-in apps to update a record in another system with xMatters alert 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 alert 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. If you want to work with these integrations in Flow Designer, instead of the Integration Builder, there are some things you should know.

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 alerts related to the ticket.

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