Handling Errors in Integration Workflows

You will need decide on a protocol for handling errors and failures when automating tasks through Integrations. These errors may occur due to the following reasons:

  • External systems going down

  • Credential expiration

  • Network issues

By default, when any given action's step fails the automatic short term and long term, retry logic will come into effect. In this scenario there is an immediate short term retry after which messages are placed in the dead letter queue (DLQ) for review. For more information, see Integrations: Halting and Errors.

This default behavior, however, can be overridden. Overriding is supported at each workflow action step to provide more control on error handling.

Implementation

Override Error Behavior

Default behavior can be overridden for any action (e.g., System, OneTrust, Database). This is done by navigating to the Settings tab for any action, then switching over the behavior from Default Error Handling to Continue on [Error].

Once this is set the workflow will continue to the next step irrespective of if the call was successful or not. You will have access to the response status code and response body in both scenarios.



Configuring Conditional Logic

Overriding error behavior only allows the workflow to continue with the error. To handle errors, you must add a conditional logic step as a following step to the action.

The condition itself can be based on a responses from previous actions steps. You can also search for the existence or the absence of a particular key. This is useful in scenarios where external systems always return a success value, along with any errors in the body.



How it Works

When an action call fails, the workflow terminates by default and no further steps are tried. Choosing to continue with the error will push the workflow to the next step.

It is up to the user to configure the workflow in a way where the conditional logic and any steps beyond the logic can work with the available relevant values.

All logs will be accessible and available for review. For more information on handling errors, see Integrations: Halting and Errors.

Handling Error Use Cases

A typical use case is seen when an automation workflow is either trying to access a user profile in an external system to either serve a Data Subject Access Request (DSAR) or update consent and preferences. An example of serving an access request would include the following steps:

  1. Looking up a user profile. If it cannot be retrieved a 404 not found maybe returned from external systems.

  2. In this case a continue on error can be used on the above step that looks up the user profile.

  3. A conditional node can then be added to check if the response status contains a 200 code.

  4. If the result to the above is true, profile data can be retrieved and posted back to the DSAR Results Summary API.

  5. If the result is false, the subtask can be updated with a failure status and a comment can be made indicating that the profile was not found in the system.