Try/Catch

The Try/Catch action allows you to handle errors gracefully in your workflows. Instead of stopping the entire workflow when an error occurs (like a failed API call), you can define a specific Catch path to handle the situation—for example, by showing a helpful message to the user or trying a different operation.

How it works

This action works by creating a special block with up to two distinct branches:

1

Try

This is where you put your main actions. The workflow will attempt to execute these actions first.

2

Catch

If any action in the `Try` branch fails (throws an error), the workflow immediately stops the `Try` branch and jumps to this `Catch` branch. This is where you handle the error.

How errors are triggered

The Catch branch executes when an error occurs in the Try branch. This happens in two ways:

• Automatically — When an action fails (e.g., an API request returns an error).

• Manually — When you use the Throw Error action. This allows you to stop execution and handle logic errors (like invalid inputs).

The Error Object

When an error is caught, the Try/Catch action exposes a caughtError object that contains details about what went wrong. You can access the values of the error in the binding panel in the lightning bolt tab.

The object contains the following properties:

Property	Type	Description
message	String	A readable description of the error (e.g., "Network Error" or "Email is required").
name	String	The name/type of the error.
cause	String/Object	Additional technical details or the underlying cause of the error (if available).

When using the Throw error action, you are able to manually define the message and cause that gets passed.

You can bind these values to other actions in your Catch block. For example, you could bind a toast notification's message to the message passed in the error to show the specific error to the user.

Advanced Patterns

Using with "Throw Error"

The Throw Error action is the perfect companion to Try/Catch. While system errors (like a failed API request) trigger the Catch block automatically, you can also trigger it manually using Throw Error.

Here is an example use case with logical validation:

Try

1

Validate Input

Use an If action to check if the inputs are valid.

2

Throw Error

Inside the True branch (input is invalid), add a Throw Error action with the message 'Inputs are invalid'.

3

API Request

Call your API. If this fails (e.g. network error), it will automatically trigger the Catch branch.

4

Success Path

Continue with normal logic (e.g. Change Variable).

Catch

1

Handle Error

Use an Open Popup action. Bind the text to caughtError.message to show the specific error (whether it was the API failing or the 'Invalid inputs' check).

In this flow, both an automatic error AND a manual Throw error action are handled by the same Catch block.

Re-throwing Errors

Sometimes you may want to handle an error (e.g. show a toast) but also let the parent workflow know something failed and stop it from continuing.

1

Try

Execute an action that might fail.

2

Catch

Show a toast notification to the user.

3

Re-throw

Add a Throw Error action at the end of the Catch branch. This ensures the parent workflow knows the operation failed and would cause it to error, resulting in it not continuing.