by As we’ve seen so far in our Power Automate articles, any user can quickly create one and start dragging boxes to create a complex workflow of actions. It’s all well and good when the Power Automate runs, but when there’s an error, then it stops and can create issues in your data. You should have a plan for errors and timeouts so that you don’t introduce errors in your workflow as well as keep things running without your constant intervention.
Example of an issue
Let’s say that you have a list that contains a numeric value that includes the stock of a product. You also have the details of the product and the purchases made for that product so that you can ship it. Now let’s think of the following Power Automate:
- Client buys the item and data is saved to the list
- Get the details of the item
- Send an email to the user with the details of the purchase
- Decrease the stock
Quite a straightforward group of steps, right? But what if you’re getting the details of the item, and provide an ID that doesn’t exist in List? Or if there’s an error sending the email? You register the purchase, but don’t decrease the stock because the Power Automate fails before that, so you will have issues when more clients try to buy the same item, and it’s unavailable.
Power Automate has the answer
Although you always see the “Success” path in your workflows, you can define failure paths that fall under three categories:
- Has failed
- Is skipped
- Has timed out
We’ll check each one and see how you can manage errors and timeouts efficiently.
Has failed
Failure can happen when you try to access a file that doesn’t exist or try to get an item from SharePoint that is not there, to name a few examples. It can quickly happen, and you should prepare for that. It looks something like this:
As you can see, the ID that we provided doesn’t exist in the list, so it fails.
is skipped
Skipping cannot be though of as an “issue” or a “problem to deal with” since it occurs naturally in your workflows. Here you’re not looking for errors and timeouts but for actions that are skipped because they either don’t make sense or there are actions that don’t allow them to run. For example, if you have a Condition, one of the conditions will be skipped (either the true or the false one). A good practice is to check, even if you’re sure that it will always be a specific value, so if the other. If the other occurs, it means that something went wrong, and you should be warned or take measures to avoid this.
Has Timed out
Timeouts happen, for example, when you trigger an approval action, and no one replies to it in the max time (for now, it’s 30 days), so there is a timeout of the whole process. It’s essential to take actions if there is no reply so that you can:
- Trigger it again.
- Scale the request
- Send a notification
The important part is to take some sort of action. Otherwise, the problem will not be visible until you check the run logs.
If you don’t know, now you know.
Before we go into this, you need to know that Power Automate allows for different branches. It’s not the same as a condition, but it’s two parallel paths that can occur. You can build one by selecting the “Add a parallel branch. “
Add an action to it.
These can be quite useful when you want to run several tasks that can take some time in parallel and gain some performance because you don’t need one to finish for the other to start.
Using parallel branches for error management
Now that we’re aware of parallel branches, we can start thinking of how to process the errors and timeouts. Let’s start with the first case that we presented. We search for an item that doesn’t exist. To catch this, we do the following:
- Add a parallel branch after the Get item
- Now let’s add an email to notify users that something went wrong.
- If we leave it like this, both branches will run. We want the second branch to run only if there’s an error, so we need to do the following:
- Change to “has failed”
- That’s it. Notice that now the arrow is dotted, meaning that it’s only running when something wrong happens.
More usages of parallel branches
There’s another widespread use for parallel branches, and that is when you want to check if a value exists or not. If not, create it and move on. Using the example before, you can try to fetch the client and, if he/she doesn’t exist, create it in SharePoint and then use that client to save the order. To achieve this, you need the parallel branches to converge after one or the other task is done.
Disclaimer The better way to do this is first to check if the client exists, then act accordingly, but with fewer actions, we can achieve the same result.
To achieve this, let’s do the error handling as before.
To converge both branches, all you have to do is create an action right after both, like this:
And then generate any action, and both paths will converge.
Nice right. Now you’re dealing with an error without the whole Power Automate failing. The system becomes self-healing since, when some data doesn’t exist, we catch it, deal with it, and move on.
Why is this so important
Power Automate makes it easy for you to start building them and forget about them. You save both time and money by having tasks automated so that you don’t need to perform them. But if you have to check to fail workflows constantly, you will end up spending more time fixing issues in the data so that the Power Automations can run correctly, defeating the whole purpose. It’s super important that you take this seriously and deal with errors so that you can save time and don’t have issues with data inconsistency.
Have a suggestion of your own or disagree with something I said? Leave a comment or interact on Twitter and be sure to check out other Power Automate-related articles here.
Photo by James Pond on Unsplash
