Notifications and Error Handling Tips

For anyone who’s dabbled in Power Automate before, you will be aware of the automatic error summaries sent by Microsoft each week. 

This acts as an automatic function each week sending a summary of errored workflows. For any important workflows, this won’t be too helpful as you may not be aware of any failures until 5 days after the issue.

As an alternate for a more proactive Power Automate Admin, you can view the analytics from the Power Automate Admin centre here:

This contains a nice dashboard of your recent errored flows. This can go up to the last 28 days and will refresh the data roughly every 3 hours. This is a good tool for overviews on which flows are regularly failing and may need some updates.

For a far more granular error handling experience, you will want to leverage the ‘Configure Run After’ feature within your flows. You can do this by selecting the ellipses menu for your step, then ‘Configure Run After’.

This allows you to conditionally set what conditions are required to occur for an individual step to run. By default, each step only runs when the previous step is successful. This however can cause a lot of issues if an innocuous step fails, the entire flow comes to a halt. By using ‘Configure Run After’ we can choose to continue the workflow should that step fail or time out. Note, timeouts commonly occur in long running approval workflows after 28 days.

For instance, my workflow has a step to update an On-Premises document. This may be prone to failure and when it occurs, the IT team may need to check the network and manually provide the update. I’ve configured my flow to send an email notification only when the previous step fails or times out.

I then configure my following approval step to run after the email notification has either been successful or skipped. This means that even if the error doesn’t occur and my alert is skipped, the flow can run as normal.

You can further enhance your run after by adding parallel branches.

With my branch in place, I can run separate actions depending on the outcome of my error.

If the step is successful my flow will run as normal, however if it fails, the IT team is notified and a rollback occurs on the item that was previously updated before terminating the workflow.

SharePoint document approvals are the perfect example where a user notification can come in handy.  Above is the error handling of two common user issues that can occur in an approval workflow. The user may leave the document open which will cause steps the error when updating the document or its metadata. As well as that, a user may leave a required field blank when initiating the workflow. In both cases, I have an HTTP Call to SharePoint to update a single field.  If either of the steps fails, the user is notified on how to fix the issue and the workflow is terminated. It’s important to keep these steps at the start of a workflow before anything that would need to be rolled back occurs.

By being clever with branches and ‘Configure Run After’ you can increase the capabilities of your workflows to handle common errors and keep user confidence knowing that when issues do occur they’re being supported.

When approaching your error handling and structuring your workflow, there are a few points you’ll want to consider early on to maximise effectiveness:

  1. Do I have any steps that me be unable to be rolled back in case of error?
  2. Are my users triggering the workflow manually to be aware of what has errored?
  3. How likely is this individual step to cause an issue?

1. Managing Error Ordering

Certain steps and features will be easier to roll-back than others if your workflow fails. For instance, an integration step to an external system you don’t have direct control over. You may have the ability to push or pull from the system but deleting an item may be a privilege that’s unavailable using an API. A good example of this would be archiving a document or record to an external system. If you order your flow to update the record in your system before archiving externally and the archive fails, your records are now mismatching, and manual intervention is needed. Conversely, if you order the archive first and it fails, you can simply notify the user and terminate the workflow. This means no change has occurred, so your records are still in the same state. Ensure you order your workflows in a way that allows a rollback to undo errors effectively.

2. User Awareness of Workflows

In some instances, your workflows may be triggered automatically. Whether this is from a schedule, create / modify, nested workflow, or PowerApps button, your user may be unaware that a workflow is running and what is happening. Your error notifications should be structured in a way that your end users can piece together what has gone wrong and what the ramifications are. In some instances, notifying your users may be counter-productive if an error occurs for something they would never notice or would not impact their own role. Error notifications are best used in instances where the user either must know if an issue occurred or they can resolve the issue themselves.

3. Likeliness of Errors Occurring

At a certain point, you won’t be able to handle every single possible error. If you did, you’d end up with an infinite amount of error-handling clauses on your error handling clauses and rollback procedures. For something as simple as sending an email or setting a variable, it’s unlikely you’ll ever see those fail short of Microsoft servers going down. And at that point, you’ll have bigger fish to fry first. Your error handling should be focused on key steps that would have a chance of timing out or failing due to user error. Good examples of these would be:

  • Connecting to an On-Premises server where availability may be spotty, or your connection may time out
  • Updating a record’s properties where a user can accidentally leave the document open or miss a required field
  • Connecting to external applications that you have no direct control over
  • Triggering nested workflows

Focus on being able to handle the 80-90% of extremely common failure points and manually handle the rare exceptions.

This is just the beginning of building more user-friendly workflows and the easiest way to improve is to continue building and refining. You’ll start to see the quirks and nuances of your systems and users and be able to predict where issues may occur before you’ve even tested the workflow. The best tip I can give for building effective error handling is understanding where your errors will occur in the first place.

Learn more about our Power Platform solutions.