SharePoint Connector’s common error messages and their resolutions in Power Automate

Today, in the series of error handling posts I will look at the SharePoint connector’s error messages.

I’ve looked at

• Handle trigger failures
• Finding failed flow actions – Part 2
• Finding failed flow actions – Part 1
• Advanced Error Handling
• Throws in flows
• Try / Catch

All of these solutions follow the principle of “something has gone wrong and now deal with it!”. This can make you catch section in your flow fairly complicated when you try to handle all failures within a single catch. Taking the Try/ Catch principles from all languages like C# and JavaScript you might want to use a try catch around your main code collecting all failures of your code however you might find that within each method/function. You will have an additional try & catch in your code.

So for the larger flows where you might develop you flow with state driven switch ( state machine alike ) then you could add a try and switch scope box around the code within each branch of your switch step. This then may help you develop a more robust flow but be careful that you don’t over engineer your flows. As flows grow you sometimes might want to wait implementing a flow straight away as a state machine.

Anyway, I would still like to suggest a base setup as shown below.

There is however still one issue. In your flow analytics you will still see your handled errors coming through.

How do you recognise the handled errors and the errors that haven’t been handled. This could be difficult and you might some of the problems that need your attention.

In this post I’m listing common error messages that I received from the the SharePoint connector. Yes, I know Microsoft Flow is not just about SharePoint, but a large part of the users is migrating from SharePoint Designer workflows.

Action Failed

The Action Failed errors can be ignored as this is the eror that Flow reports when an action inside a condition, scope, an apply to each or switch is failing. So when you see these error messages you should investigate a failure inside the step rather than the step itself.

Error 429

I’ve seen the 429 Error happen quite a few times when my flows were overloaded with updates. In the error details you will likely see a Rate limit is exceeded. Try again in 1 seconds. The SharePoint connector has been limited by the number of calls to SharePoint.

This can happen within the When a file is created or modified (properties only) trigger in which case you are going to be stuck. It would help if we had an option to handle trigger failures.

If this error happens at a later stage of your flow, you could look at redesigning your flow a bit. In the below example you can see the 3rd action of the flow failing:

Recently however the When a file is created or modified (properties only) action was updated and more information is returned therefore you might not need that Get file properties action anymore.

The other option of reorganising your flows is pushing some of the steps lower into flow.  Especially with flows that update the triggering item you will find that you will be running many ‘unwanted’ instances of your flow. If there is any check that you could build in before you run your first action  then that will reduce the number of SharePoint calls. You may not be able to avoid the trigger but you might be able to avoid follow up steps.

Conflict

Conflicts are an other difficult to handle failures of flows. These failures can happen within the update property actions but also in the Create file. Within the flow details you might see the following error:

Save Conflict

Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes

This one is not nice as there are two reasons for this failure:

• A user makes an update to a file the same time as you make an update.
• Multiple flow instances are doing something to a file in SharePoint.

It would help if co-authoring existed within the SharePoint connector.

In this case you could build in a retry however this might not help and you might end up over engineering your flow. Quite often you can simply ignore these failures. If you have multiple flow updates happening it could simply be that the  two flow instances are doing the same anyway.

Within some of my flows I also noticed the conflict error in an update file properties following a create file. Looking at the flow run history it looks like the file was still being created while the update file properties has already kicked off and failed.

BadRequest

The BadRequest error might show you details like:

The file Folder/File.xlsm has been modified by i:0#.f|membership|username@domain.com on 29 Jun 2018 08:01:00 -0700

This is a similar error as the earlier mentioned Conflict. I’ve also seen this one happening often when flow runs an Update file properties straight after a Create file. It might be important to handle these errors as they might simply happen while you create larger files or when you create files when the system is slower and therefore the file creation takes longer than expected. Quite often a retry on the Update file properties resolves the issue.

Not found

The not found error can be a weird one. How about a create file action not found?

You might even get something like this:

Did not find the File : /DocumentLibraryUrl in Site : https:/ /mytenant.sharepoint.com/sites/site/siubsite/. Ensure that the File Exists

This feels like a completely random error of the Create file actions. My Document Library hasn’t been unavailable!

Have you thought about putting a switch after the Create file so that you handle all the different failures?  You could of course put a try catch around the create file action and in the catch give it a second go to create the file when you get this 404, NotFound?

Unauthorized

How about some random trigger failures giving Unauthorized

The response is not in a JSON format

And once again the create file can also give this failure. For the Create file there are no further details

BadGateway

The update file properties might give you a bad gateway.

The bad gateway error happens when you try to push invalid data into a SharePoint list item or document. This is where you need to make sure that your data is valid before you try to do the update. Within the error details you might find something like this:

{
  "error": {
    "code": 502,
    "source": "europe-002.azure-apim.net",
    "clientRequestId": "653a6b96-de18-4976-ad49-e1047c84bf68",
    "message": "BadGateway",
    "innerError": {
      "status": 500,
      "message": "Error converting value {null} to type 'System.Int64'. Path 'Id', line 2, position 13.\r\nclientRequestId: 653a6b96-de18-4976-ad49-e1047c84bf68\r\nserviceRequestId: 6a88749e-101c-6000-db79-b1c4343f5f84"
    }
  }
}

By building in a few extra checks before doing the update you will find that these bad gateway errors will go away.