Microsoft Flow is a great product that lets you trigger processes when items or files in SharePoint are changed. This works very well and better than in SharePoint Designer, however there are a few limitations that need to be addressed.
1. The Created or
When a flow is triggered on the modification of a list item or a file then it should be possible to get the current and previous values of the fields that were changed.
This will help when you want to check in a condition if the value of a specific field has changed from one value to another.
At the moment flows trigger when items are modified and it isn’t possible to filter on which modification was made. It would help if you could for example trigger a flow just when a field has been modified or not trigger if a specific field has been modified. Currently the workaround is to use a condition straight after the trigger, but that still adds a run history for the flow.
3. Triggers available for SharePoint.
Currently Flow offers 7 triggers. Some triggers are really missing.
- When an item has been deleted
- When a file has been deleted
- When a site has been created
- When a site has been deleted
And then there could of course be more, but these are the ones that I have been missing.
4. Run a flow as …
As part of the trigger configuration it would be nice if it was possible to run the flow as a different user. Although I could also imagine that this could be implemented as a part of a scope in a flow
3 thoughts on “Microsoft Flow – SharePoint triggers and their limitations”
I think you will find the specific field in an item changed is a bit of a challenge as Share point appears to only ever write entire records in one operation. I could well be wrong but it does not just update one but the entire record.
Run flow as could be tricky as you would need to ensure security from each action is good.
As for creation of new sites I think plumsail has that in it. However I am sure it will be part of new site designs. As you can run a flow from that when a site is created.
Certainly nice if at least when the flow runs it picks up the previous values and has them in the log and necessarily as dynamic data items. As that might be confusing in the flow as to which is which value.
Just my thoughts
Currently the workaround is to use a condition straight after the trigger, but that still adds a run history for the flow.
Is there a tutorial or blog about this workaround?
In general I am less worried about the number of runs as when you share your flows the run quota is shared too:
Also, thinking about using state machine contructions might help too: