Integration Workflow Tips and Tricks: Mid-Workflow Webhook

There is an art to building integration workflows especially so when you want to achieve the best value from integration software.

Today we dive into how a mid-workflow Webhook can add further customisation and functionality to your workflows.

Add Further Webhook Functionality to Your Workflows

The workflow you’ve created is up and running, data is flowing, and updates are happening.  However, there’s one thing that niggles. The integration workflow would be better if you intervened at one point. This could be an external decision to execute the next step or skip it.

What to do? Split the cycle into separate cycles?  That seems like overkill. You don’t need to store any data; you just need someone to make a decision during the cycle.

Cyclr provides an easy way to intervene in a workflow without stopping it and wait for relevant information from an external source to determine the next action: the mid-workflow Webhook.

Webhooks

Webhooks are used for event-driven integrations and are one of the many ways applications can communicate with each other. They allow you to send real-time data from one system to another when a given event occurs. 

You may already be familiar with Webhooks and how they are often used as the first step in an integration workflow. However, a webhook step can be used at another point in a workflow. This gives you the power to wait until additional data arrives from another source.

Say your cycle webhook receives new account details, and maps the webhook request fields to the Create Account in the next step. But then a manager needs to confirm account activation – and who knows how long that could take. How do you manage the cycle to implement that requirement?

With a [MCW], you can add a step to email or notify the relevant manager for confirmation, including the [MCW] URI. 

When the cycle step receives their response, you can use one of Cyclr’s Integration Tools such as the Decision Step to divert to the appropriate step based on the values received by the [MCW]

Access Approval Request

Step Permissions Webhook Request extended access

Receives a User ID from a third party, or this could be from a step request in another cycle.

Step Salesforce/Get User

Get the details for the User ID received in the previous step.

Step Slack/Post Message

Send a message to the approver, with the user details.

Step Permissions Webhook/Approver Response

The cycle execution awaits the response from the approver.

Step Decision Step

Request approved, control is passed to the Salesforce/Update User step, else to the Slack/Post Message step.

Step Salesforce/Update User

Send a request to Salesforce to update the user with the extended access permissions.

Step Slack/Notify Approval

Send another message to the approver to confirm that the user update has been requested, and include relevant Salesforce response details.

Step Slack/Post Message

If the approver declines the request, send a final message to confirm that the user has not been granted access.

Webhook Mappings

When using a mid-workflow Webhook you’ll need to add mappings to the step to interact with the webhook. This tends to look something like this:

Mid-workflow Webhooks have a Webhook Mapping section in Step Setup where you define what will trigger a Transaction to continue: you select the field in received Webhook Requests that will contain a value that matches another field found in the existing Transactions, e.g. a Job or Order ID.

Each time the mid-cycle Webhook receives a Request, it will look for the most recent Transaction that has a matching value for the Webhook Mapping defined, and run that Transaction from there. This can be done multiple times, causing a Transaction to be run from the mid-workflow Webhook more than once. This can be useful when processing data such as Orders where a notification might be received each time its status changes (e.g. from Received, Picked, Packed to Despatched). In this situation, if you only wanted to continue when the Order’s status was “Despatched”, you could use a Decision Step after the Webhook Step to check the current status.

Field discovery: link to docs to explain how to get available fields from a webhook request to the endpoint.

Conclusion

Mid-workflow webhooks provide you with a simple way to intervene in a workflow when an external decision or information is required, without storing data or pausing the workflow execution.

Learn more about Webhooks