Error Handling

In the previous step, you learnt about variables and looping. Variables are initialised and can be set, incremented, or decremented depending on their data type. They can be used in condition criteria, used to hold a value you plan to use later. Looping repeats workflows until a condition is met.

When everything goes as planned, a flow will run from top to bottom and successfully complete.

An essential part of building a good flow is thinking about what can go wrong and taking the necessary steps to handle the error and compensate (recover for the work already completed by the flow before the error occurred).

For example, if during a flow’s execution a record was created, then the flow did some more processing and an encountered an error, you might want to clean up and remove the original record or create a task for someone to follow up and manually fix the problem. By default, when the error occurred your flow would fail and stop the execution. An administrator could resubmit the flow, but that would start execution at the top again, likely creating a duplicate record and potentially failing again. Ideally, flows would be designed to be able to be restarted with minimal manual intervention.

An important concept to keep in mind is the work completed by each action in a flow is independent of others and work completed previously will not automatically be undone if a subsequent action causes the flow to stop.

By default, a flow will keep running through its steps as long as the prior actions have been successful. Most actions in your flow can be configured to run on more than just successful completion of the prior step. This is done by configuring the run after settings on each action.

Clicking this shows the following configuration panel that allows you to modify the configuration for the action.

Failed – any type of failure other than a timeout. For example, if the user did not have permission on the entity or the field you were filtering on was invalid.

Skipped – the prior action was skipped, this could occur for example if the prior action had the default configuration of run only when successful and the action that preceded that failed.

Timed out – this could occur when a call to Common Data Service or other connector times out. Some steps like approvals allow setting the timeout and by handling timeout you can treat it as a planned execution path.

When you are not allowed to configure the run after the option will be disabled. For example, you can’t configure it on the flow triggering action, or the one following the trigger, or the first action inside a loop or scope.

Often when you use the configure run after you will find the need to also use a parallel branch. The parallel branch allows you to have the run after on one branch be only successful and the other branch handles the errors or timeouts.

In the following example, the left has been configured to loop through all the contacts on the account when the action is successful, and the right is configured to send a mobile notification when the list action fails.

You can take error handling too far and add too much error handling and make your flow overly complex for situations that will not frequently occur. Alternatively, sometimes small changes can make a flow more resilient to restarts. For example, if you add a query to check if a record existed before creating it if the flow had to be re-run it would not create a duplicate record. As you build your flows, look for places that might be more likely to have errors and handle them as needed.