Power Automate: Fail-proof your Power Automate

Having Power Automates running is easy but making them fail-proof is not has hard it may look when compared with the benefits that it brings. As an example let’s use folder extraction. Power Automate provides us a handy tool to extract folders from a SharePoint source to a destination. You may be wondering when is this useful so I’ll give some ideas to get you started:

  1. Receive a ZIP email and import all files to SharePoint.
  2. Have an archive with templates and unzip it to a folder each time you create a project.
  3. Go back to an archived file, and put it back into a folder for review.
  4. Have a Microsoft Form that receives requests from people that are uploaded, unzip them, and parse them.

There are multiple ways that this can be useful, but I wanted to show you how to do it.

The basics

So how will we make our Power Automates fail-proof? I’ll show you a real example that I use all the time, where I have a Template Site in SharePoint, where I keep all Project templates. I can have models for multiple steps of the project or the overall project, but in this case, I want to start with the requirements step, so I have a ZIP with the requirements files (and Excel, Word, and PPT) to choose.

After this, we can simply have a Power Automate that collects the destination folder and unzips the file there. Simple as:

The formula is quite simple:

concat('/Shared Documents/Projects/',triggerBody()['text'])

The idea is to create, in the Shared Documents > Projects folder, the new project that we’re creating. When I say the project, you may think about something complex, but if you have a blog, for example, you can use the same concept to store your ideas. You can have a zip file with all your folders and template files, and when a new idea strikes, you can trigger the Power Automate and creates the folders for you. I use this myself with the following structure:

I use this structure in all articles I write, and it’s all compressed in one zip file that I trigger, as you see above.

  1. A default mind map for the more complex articles
  2. Raw images that I’ll edit later
  3. I save the processed images (with annotations, etc.) to the “Processed Images.”
  4. Then I have an automatic process that fetches the image there, scales it for the web, and saves it to “Ready to upload. “
  5. Other Files to Upload are where I store zip files, templates, and other things I want to upload.
  6. Temp Files is where I put something that needs to be parsed or prepared to upload, but it’s not ready yet.
  7. Movie Files contain the screencasts that I do for specific articles.

Nothing fancy is needed, but this is my structure. Going back to the topic at hand.

Planning for errors

Planning for errors is always something that we leave for “after” when we’re in a pinch or confident that “it will never happen X.” Well, in IT, “X” always happens, and we need to be aware of it. I wrote an article about how to plan for errors and timeouts, but I want to show you how it can make it applicable in Power Automates that we build, making them, with simple changes a little bit fail-proof.

If we run the previously with the value “Article” created Power Automate we get the following:

It even creates all the folders for us, if they don’t exist and we get:

So far, so good.

Now let’s say that we want to create a project called “Automation / Inbox Cleaning.”

We get an error, the Power Automate crashes, and the following steps, if there were any next steps, they would be not be executed. It’s quite simple to break it.

So why do we have an error?

The error is somehow misleading, but the main reason is that we’re using a character that you can’t use while building folders. The “/.”

The issue is not the error itself, but what I want to show you is how to have a Power Automate that, even with them it becomes self-healing and runs until the end. So let’s make it fail-proof.

Adding error validation

Adding validation to errors is quite simple. Create a parallel branch and add actions that would trigger when an error happens. So let’s add it:

And now the action to when there is an error:

There’s only one more thing we need to do. To say that the path that we’re running is only triggered if there’s an error. To do that:

Add the ones that you want to “catch”:

And you’re done:

If we end it like this, the Power Automate will still return an error. It makes sense if you think about it since there is, in fact, an error. To avoid this, since we dealt with the error, we need to add a terminate to override that:

After this, we still need to indicate that it runs after an error. Otherwise, the error would propagate from before and will end the Power Automate with it. To change that we do the same as before:

Run after everything:

And we’re done.

Another example

Let’s complicate a little bit further and use an approval process as an example. When you trigger it, Power Automate remains “Running” until the person or people take action. But a Power Automate can only run 30 days max, so if there’s no action in the Approval process, the Power Automate will fail. If you have a lot of approval processes, you need to check the ones that failed or not to check who didn’t reply, and this is not very efficient, so you want it make it as fail-proof as possible.

The solution is to have a branch that “catches” these cases and deals with them. Let’s focus on the other part on the Power Automate since the first one is well taken care of in the previous section.

To achieve this, we need three branches:

  1. All is ok
  2. if there’s a timeout
  3. Any other errors.

To create branches, we follow the same steps as before but configure each as follows:

Now let’s set the second as before:

It will only run if there’s a timeout. Then you can send an email to someone warning of the issue.

The third as follows:

Then there’s an error, so you should take action differently.

Final thoughts

We started with file management and ended up a little bit further, but I want to demonstrate two things:

  1. You should always take care of the errors so that they don’t break your app
  2. You can parse them individually and take different actions for different types of errors.

Always be aware of the errors and deal with them. If you ignore them, they will come back to bite you, and you’ll regret it. Having a completely fail-proof Power Automate is tricky, but with some work, you can get quite close to it.

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 Microsoft Power Automate-related articles here

Photo by jean wimmerlin on Unsplash

Manuel Gomes

I'm a Project Manager with experience in large projects and companies. I've worked in the past for companies like Bayer, Sybase (now SAP) and I'm currently working for Pestana Hotel Group.

View all posts by Manuel Gomes →

Leave a Reply

%d bloggers like this: