You can find many problems when using Power Automate and Azure Logic Apps with complex SharePoint lists. This article will cover another one that cause triggers to break. If you use the “When a file is created or modified in SharePoint” trigger, keep reading.
Some time ago I wrote a blog post about a different issue caused by columns not indexed. You can read more here.
You may also encounter broken triggers when you try to use large SharePoint lists, that contain many complex columns (managed metadata, lookups, …). The “When a file is created or modified in SharePoint” trigger, may work for some time, and then suddenly stop.
If you use a Power Automate flow, you may not be able to see error details on the screen.
Using an Azure Logic App, you can see the error details for the failed trigger by checking the trigger history.
File created or modified trigger error
Click on the trigger execution you want to inspect and on the right panel click on Outputs link. The body of the response will contain error details and will look like this:
"body": {
"status": 400,
"message": "The given guid does not exist in the term store\r\nclientRequestId: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX\r\nserviceRequestId: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}
Solution – limit columns by view
The solution is very simple and all you need to do is specify a view to limit the number of columns in the trigger.
The best option to prevent this from happening may be to always ensure that you set a view on the trigger.
If your trigger is currently broken and suffering from this problem, you may see it working again straight after you hit the save button!
Update
If you still experience issues after specifying a view, this is likely because the view specified still has too many (complex) fields, like metadata. Create a new view using only basic columns (for example: name, created, created by) and try using that one.
Hi Joel, I have the opposite problem as in I set the check for items to the default 3 mins and my logic app fires repeatedly, at this configured time – regardless of if there are any new or modified items. I guess this leaves the option of increasing the check for items interval which has obvious downsides. Also, I don’t get a conditional trigger as such so do you have any recommendations?
Hi Daniel, not really sure about the scenario you are experiencing on the logic app firing repeatedly. Do you have the logic app updating the same item by any change, and as a consequence triggering itself again? Are you able to inspect the running executions and check what item is causing the trigger?
Hi Joel, nice explanation.
I have the same issue on my logic apps app. I tried to do your recommendation by using the minimum number of columns in a view then use the view in getting items (ID, contentType, DocumentID) but unfortunately I’m still getting the same issue.
Could it be something really related to using a metadata that has been deleted in the termstor?
I would appreciate your recommendations
Regards,
Hi Mohammad,
Thank you. In my case, I used a view with only: Name, Created and Created by. After the trigger, I just retrieve the item with all the properties I need.
This solved the issue for me, and at the time I was also thinking it was down to metadata. Had a support call with Microsoft for many weeks that was passed from team to team, and the issue immediately disappeared as soon as I configured the view.
Also make sure that the columns on the view used by the trigger are indexed as mentioned on the other article that I link on the second paragraph.