Try/Catch shape

Introduction

Using the try/catch shape, you can build your own path to handle process flow sync exceptions elegantly.

Place a try/catch shape before key steps in your flow, then configure its settings to determine behaviour when exceptions are found. Once this is done, the shape is added to the canvas with two routes - one for try and one for catch:

For the try route, build your flow in the usual way to achieve the required result. For the catch route, define a flow that should be followed for exceptions. For example, you might add exceptions to a cache (so they can be processed subsequently) and then notify specified contacts that exceptions have occurred.

The notify shape can be very powerful when used with the try/catch shape. Keep in mind that you can include meta, flow, and payload variables to define notification messages. For example:

When the process flow runs, data flows down the try route and ideally completes without exceptions. However, if an exception is found, the associated payload is removed and sent along the catch route.

You can add one try/catch shape per process flow

Need to know

You can add one try/catch shape per process flow
If a connector needs to retry authentication, the retry is NOT caught (i.e. it's not sent into the catch route). If re-authentication is successful the flow continues as normal (i.e. along the try route), otherwise the process flow fails.

Caught exceptions

As noted above, if an exception is found it gets removed (as a failed payload) and sent along the defined catch route. For example, if a try/catch shape receives 20 payloads and finds 4 exceptions, then 4 failed payloads are sent along the catch route.

Failed payloads can be found on the failed payloads tab in run logs - for example:

Adding & configuring a try/catch shape

To add and configure a new try/catch shape, follow the steps below.

Step 1 In your process flow, add the try/catch shape in the usual way:

You can add one try/catch shape per process flow. It's up to you where you place this in your flow, but it's generally a good idea to add it at the very start to ensure that all steps are checked.

Step 2 Access settings for the newly placed shape:

Step 3 Choose the action to take if an exception is encountered:

Available options are summarised below:

Action Flow behaviour

Action	Flow behaviour
Succeed as partial success	The flow completes and, where possible, data is synced. Failed payloads for exceptions are removed and are available from run logs. The flow is logged with a status of `partial success`.
Fail flow	The flow completes and, where possible, data is synced. Failed payloads for exceptions are removed and are available from run logs. The flow is logged with a status of `failure`. In this case, the flow is marked as a `failure` (and will show as such in run logs) but it's important to note that this does not cause the process flow to stop - any valid payloads continue through the flow. It's likely that you would only use this option instead of `succeed as partial success` if logging any failed payloads as a general flow failure is important from a reporting/metrics perspective.
Fail flow & retry	A retry will only happen if the process flow is enabled and deployed, and is NOT triggered manually. The flow completes and, where possible, data is synced. Failed payloads for exceptions are removed and are available from run logs. The flow is logged with a status of `retried`. The flow is retried with ALL data. The flow is retried ONCE only.

Succeed as partial success

The flow completes and, where possible, data is synced.
Failed payloads for exceptions are removed and are available from run logs.
The flow is logged with a status of partial success.

Fail flow

The flow completes and, where possible, data is synced.
Failed payloads for exceptions are removed and are available from run logs.
The flow is logged with a status of failure.

In this case, the flow is marked as a failure (and will show as such in run logs) but it's important to note that this does not cause the process flow to stop - any valid payloads continue through the flow.

It's likely that you would only use this option instead of succeed as partial success if logging any failed payloads as a general flow failure is important from a reporting/metrics perspective.

Fail flow & retry

A retry will only happen if the process flow is enabled and deployed, and is NOT triggered manually.
The flow completes and, where possible, data is synced.
Failed payloads for exceptions are removed and are available from run logs.
The flow is logged with a status of retried.
The flow is retried with ALL data.
The flow is retried ONCE only.