Workflow Automation CoE > Flows > Flow and Action Error Handling > Level 1: Retry and Action Error Evaluation
Overview
We want to catch errors immediately when we build flows, subflows, or flow actions. This prevents them from cascading up, and we save ourselves from combing through multitudes of actions and subflows for some of our more complex workflows.
In the example use case for this article, I’m sending a REST message from a custom action, but this feature is not limited to integrations. However, action error evaluation can be used in ANY action step type like create or update record, wait for condition, script steps, JSON or Payload builder, etc.
Use case: Custom REST action
I’ve created a beeceptor endpoint with reply rules that will return different response codes and messages based on the path to which I’m sending my REST call. My custom action can then process the response code and message. In case of success, it’ll return a code of 200 (which in HTTP land generally signifies success). In case of error, it’ll return 401, signifying authorization issues. To test the Retry Policies, it returns the 408 Request timeout code.
Test REST Step
A relatively recent but handy addition is the “Test REST Step” button within the REST Step!
The REST step tester lets you see the response for each possible input and helps you build out the rest of the action. This is very useful for figuring out if your credentials and handshake are correct and working. It also helps understand what the response from the remote system might look like. One common next step is to parse a retrieved JSON payload into an object or array to map to the action outputs, and this is the best way to get an actual example payload.
Retry Policy
The first thing you can do to catch an error while calling a remote system is to try again! This is most useful if you run into a connection timeout error or a rate limit on the endpoint.
We provide a handful of Retry Policies out of the box that you can use as they come, but it’s straightforward to create your own as well. Either duplicate and adjust a default policy or create a new one to define how often and at which intervals your instance should try to execute that integration step again.
You can pick from three different retry strategies and submit an interval in seconds and a count of how often this should be retried.
Exponential Backoff: Option to exponentially increase the time interval for the subsequent retry attempts. The multiplier is 2.
Fixed Interval: Option to specify a fixed time interval after which a retry attempt should be made.
Honor "Retry-After" Header: Option to specify a retry attempt based on the date and time value returned in the Retry-After header value of the HTTP request.
Action Error Evaluation
REST Action Step - Without Error Evaluation
After handling connection or request timeouts with the retry option, we want to ensure we properly catch all non-successful step executions. Since we’ll (almost) always get any response back from the remote system, the integration step will be marked as Completed, and the Action Status will be 0 and Success because it was completed successfully!
The issue is that not all responses are helpful to us. The error details will be hidden in the step details and will not automatically surface in the action outputs. Frequently, these issues will only crop up in later action steps or subsequent actions in our flows, for example, when a JSON parser step can’t handle the response body because it doesn’t contain the expected data.
REST Action Step - With Error Evaluation
For all kinds of steps, we get to choose whether an error in this step stops the action and jumps into the error evaluation section OR if we want the action to continue with the next step. We recommend only proceeding for errors in independent steps. We should use the error evaluation section as soon as any subsequent action step depends on a step’s success.
The Error Evaluation section allows you to build several conditions and condition sets and then map values to the action status code and message. You can drag and drop the different conditions to order them for your use case.
Some errors won’t affect the outcome of your action. In these cases, you can check the box to avoid treating this as an error and keep the error from surfacing in any flow or subflow you’re using.
If you DO want the error to be visible in the flow but still want the flow to execute beyond it, we also have a solution: the TRY flow logic, which we’ll cover in the next section. You can also handle and remediate errors on the flow level, which we’ll talk about right after the flow logic section.
Once everything is set up for our custom action, it will look like this when executed.
We get a nice, angry red error status and the error message we chose in a big red bar.
Error Evaluation Tips
Before we move on, we’ll go through some recommendations for building out these conditions:
Avoid building more than 10 conditions
While there is no limit to the number of error conditions you can create, each error condition requires evaluation. The more error conditions your action has to evaluate, the potentially slower your action can run.
Order conditions from specific to general
Error evaluation stops at the first matching error condition. Putting general error conditions first may prevent the action from matching specific error conditions.
Identify specific step failures
You can use the Step Status to identify when a specific step fails. Identifying a particular step can be helpful when your action contains multiple instances of the same type of step.
You may also want to identify a specific step so that a flow error handler can take specific corrective actions for the failure.
Use descriptive error condition labels
This helps you identify an error condition at a glance without opening the details.
Continue Reading
Level 2: Flow Logic - Try, Do the following until, Go back to
Center of Excellence Navigation
