Microsoft Flow, the lazy coder’s alternative to SharePoint web hooks

SharePoint web hooks has made it out from preview and into general availability, and is a great way for applications to act on changes to items in SharePoint. Think workflows where you want to run custom business logic when someone creates or edits an item. For the old-timers a web hook is just a new type of event receiver on the created/updated/deleted events.

The good thing about web hooks is that you can tack them on using either an Microsoft Azure Active Directory application or a SharePoint add-in, using application credentials. This of course is the proper way to do it, so if you are coder-proper, then stop reading now.

So why do it the lazy way using Microsoft Flow?

If you go the route of creating a web hook programmatically you have some plumbing to do up front:

• Get an administrator to register your AAD app or SharePoint add-in
• Write code to subscribe the web hook to events on the list/library
• Write code to re-new the web hook subscription once it expires (max 6 months)
• Write code to fetch the data of the item which triggered the event

The lazy approach is somewhat a smoother ride, and is what I used at a recent hackathon to get things working fast. The drawback is that Microsoft Flow runs in user context, so you only get events on items you or the account you used to authorize a particular connection have access to – but this might work our just fine for many scenarios. Using a service account is one possibility.

If all you want is access to the data of a created/modified item and want to pass it to a custom API, then using Microsoft Flow makes it very easy. One trigger action which return data for all item fields, and one HTTP action (with swagger if you fancy that) to your custom API with a payload of your choice and you’re set. You can focus purely on the API logic and let Microsoft Flow handle the eventing for you. If you want to handle both created and modified items you need to create two flows.



I'll be fair and say that Microsoft Flow currently does not handle everything and come with some caveats.

• Currently no support for updating taxonomy field
• Currently no support for updating lookup fields
• Currently no support for updating choice fields
• Currently no support for updating people fields
• Updated items will have “you” or the account used in the connection to SharePoint as the last modified user
• Updating a list with more than 12 lookup/taxonomy columns will report as failed, even though they work

As you can see, the weak points for now are on updating items, not getting the values of the item itself - so happy flowing!