Microsoft Flow – SharePoint Connector’s common error messages and their resolutions

In my series of error handling posts I’ve looked at

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.

Advertisements

25 thoughts on “Microsoft Flow – SharePoint Connector’s common error messages and their resolutions

  1. Hi,

    I’m struggling with error 423 and the Update file properties action. Whenever a user has an uploaded document (e.g. a Word document) still open it can’t update the data in SharePoint. How do I counter this?

    Like

      1. Hi Pieter,

        You are right, it is error 400 instead of 423. My bad. I have the exact same error message. I need to be able to update my SharePoint items at all times. Do you think there is a way to solve this (with a workaround)?

        Thanks!

        Martin.

        Like

      2. Hi Martin,

        I’ve seen this mainly when multiple flows are running on the same item and the triggering item is being updated by the flow. These things can be tricky to fix. Quite often you can ignore the error ( use the run after actions) and when the 400 happens exit out of the flow and wait for the the other instances of the flow to do their job.

        Like

  2. I am now getting the “bad gateway” error when reading from a list using the “Get item” action, not the Update action. The flow was working previously fine until 6 days ago.

    Like

      1. I see this error,

        “error”: {
        “code”: 502,
        “source”: “flow-apim-msmanaged-na-centralus-01.azure-apim.net”,
        “clientRequestId”: “7efe60db-ed54-428a-b79c-201bbb8fb2a8”,
        “message”: “BadGateway”,
        “innerError”: {
        “status”: 500,
        “message”: “Value does not fall within the expected range.\r\nclientRequestId: 7efe60db-ed54-428a-b79c-201bbb8fb2a8\r\nserviceRequestId: 01b7849e-00ca-6000-4972-d018cc4386ac”

        Also, in my “Get item” action I double-checked the list name & location is correct, the Id is simply 1, and I have “Limit Columns by VIew” set to a view that displays only the single column that I want.

        Like

      2. Ok. Flow is complaining that something is wrong in the data. Can you export your flow and reimport it? You can keep the original flow as a backup. Simply disable it. Does this resolve the problem. It looks like something in the format of the data has changed.

        Like

  3. I already created a new, smaller workflow for testing and it failed the same way. If the format of data has changed, then I will create a new list w/ similar data and test on that.

    Like

      1. I tested using new flows and new lists and and new data connection. The same error occurs.

        I am going to assume this is a Microsoft bug that was introduced a week ago. It was reported by another user here — https://powerusers.microsoft.com/t5/Connecting-To-Data/Bad-Gateway/m-p/146111/highlight/false#M3346

        I will wait for it to be fixed, but I already developed a workaround. I simply hard-coded in the data that I want, instead of calling it from a list. Makes the flow less flexible but it still works.

        Also, I learned something useful, and that is to use the “Configure run after” setting to allow my flow to continue even after the error. I put my “Get item” and “Set variable” into a Scope box. If anything in that Scope fails, the next action is configured to run regardless. And the variable already had a default value. Also make sure not to run your Set Variable if the Get Item fails. Maybe this tip will help someone else out there.

        Like

  4. Thanks. Also, the Get Items (plural, not Get Item) action works in some of my other flows. I could probably configure the filter to return a single item.

    Like

  5. Hi Pieter, can you explain why sometimes, users needs to fix their connections? I have a workflow with a sharepoint connection that is using the current user authentication. Once in a while the user connection is broken. No MFA configured. Here is the error in the flow when the sharepoint connection is broken:

    “Error from token exchange: Runtime call was blocked because connection has error status: Enabled| Error, and sharepointonline is in the block list. Connection errors: [ParameterName: token, Error: Code: Unauthorized, Message: ‘Failed to refresh access token for service: sharepointonlinecertificate. Correlation Id=7d9d06a4-141b-4ea6-bcbd-aa53c3371e63, UTC TimeStamp=9/20/2018 2:47:14 PM, Error: Failed to acquire token from AAD: AADSTS50173: The provided grant has expired due to it being revoked. The user might have changed or reset their password. The grant was issued on ‘2018-08-02T16:12:35.0000000Z’ and the TokensValidFrom date for this user is ‘2018-09-19T16:03:20.0000000Z”

    Like

  6. Hi Pieter,

    I follow your blogs a lot and this particular blog has been most helpful. I stumbled upon this as I was looking to resolve several run time errors that i am getting with my flow that is triggered when a new email arrives in a shared mail box. The mail box is getting huge amount of emails and the flow is failing sometimes with 503 Service not available error, i guess this is because of the amount of requests that are being made to SharePoint while updating metadata or creating a file. What do you think about this? is there any way to solve this? Also, I am also victim of 409, Save Conflict error, where step 1 creates file and step 2 updates the metadata, so, for this i have decided to put a delay of 10 seconds in between the actions, do you think this delay is reasonable? the files can be as large as 5 to 10 mb.

    Thanks in advance – Deepa

    Like

    1. Hi Deepa,

      Handling problems with high volume and large content can be tricky to handle. There are a few ways around this though.

      For high volume problems you could look configuring retries better as described in the following post.
      https://veenstra.me.uk/2018/08/08/microsoft-flow-getting-your-flow-trigger-retries-right/

      When things go wrong (i.e. you get an error code back and there hasn’t been a retry) then all you can do is go through the same action again.

      There are multiple approaches available for this.

      1. Add a loop around the failing action
      2. Use my try catch pattern (https://veenstra.me.uk/2018/02/07/microsoft-flow-implementing-a-try-catch-finally-in-a-flow/).

      In general for large file uploads I make sure that I use the when a file is created or modified rather than just when a file is created. That way the flow will start multiple times and you don’t need to worry about the failures too much as the next run will correct the failing steps.

      Like

      1. Hi Pieter,

        Thank you so much!! I have implemented try-catch- loop pattern, i am hopeful that retrials would handle most of the runs. I was also going through your blog around trigger failures and i was wondering, when the trigger fails do we lose that run? For example, if i have written a email trigger, if the trigger fails would the email associated with it would never be processed by flow.

        Like

      2. There are two types of trigger failures
        1. the logic in the trigger fails
        2. the trigger fails to trigger

        when the flow fails to trigger there simply is no run and therefore the flow will never happen. This can be avoided with the longer retry periods.

        Like

  7. Thank Pieter! I have setup longer retries on the trigger. I am also seeing trigger failures under Failed Checks, and there is no way to rerun those, so, I am assuming that these are not actual run failures and a failed check later gets a run, is that correct?

    Like

  8. Hi Pieter, awesome piece. My specific issue is not among those you list, though.

    I’m getting problems when trying to write an empty value to a SharePoint list item column (people or group column type). This column should take an email address as input and then locate the user or group from my Active Directory and return it to the list column as an object. The problem is if someone doesn’t provide an email address (entirely optional on the input form), Flow cannot continue and gives me this BadRequest error message back:

    {
    “status”: 400,
    “message”: “No se encontró el usuario especificado .\r\nclientRequestId: a6621da1-2b86-4ab8-a7a3-6b1576e9d3a2\r\nserviceRequestId: be40e49e-308e-8000-5345-e6973546d5c2”
    }

    (Translation from Spanish would be “The specified user was not found”).

    How can I get SharePoint to treat invalid values such as an inexistent or incorrect email as simply “null” and thus let my Flow continue on to the next step?

    Thanks a bunch!

    Like

Leave a Reply to Gregory MacGregor Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.