One Flow to handle them all - Part 2 figuring out the changes

I had previously wrote a method of using Microsoft Flow to subscribe to all the lists in a SharePoint site - and how to have them all call a second Request flow to execute on File changed in any of these lists.

In that blog post, as all good trilogies go - we finished at a spot where we have gotten a webhook event call, but did not proceed to continue working out which items actually changed.

The full Get Changes Method

In the long delay between my #FlowNinja tweet and the blog posts being written, my friend @ISSPDEV couldn’t wait for the next part he went ahead with this. He wrote in much detail. 

Implementing the best practices from the SharePoint team

The Short Cut Method

I provide a second method, perhaps one that is much shorter for a Power User to implement. I worked on this with @ArtsyPowerApper and figured out a simpler method.

First upload a file, then copy the entire trigger body JSON.

Next, after the validation steps we had in the initial handler flow - we add a Parse JSON.

Use the trigger body JSON to create the schema.

By telling SharePoint to give us files updated in that library in the last 10 seconds, we fetch the changed items directly.


In my tests - I have tried 5 seconds and it seems good enough, but I extended it to 10 seconds in case there’s an large upload or delay.

Short cut method has a small risk of firing an event twice on the same item if it was somehow updated rapidly twice.

Also, unlike the complete Get Changes method, we can’t see System Update, Deletion, Rename, Permission Update events. So this method is only good for Item/File Created and Updated events.

But the steps is far simpler with a Parse JSON and one Get Files (with an OData filter)