Avoiding multiple flow executions when per-column edits are submitted in SharePoint

[Mart1]

Hi,

I have a flow which triggers on a new or changed item in a SharePoint list. The 'save' behaviour of SharePoint re-saves the item each time I edit a column and tab out to the next column. This causes my flow to trigger multiple times (i.e. each time a column is edited and the user tabs out of the field). It seems like this could become 'expensive' in terms of compute resource.

I understand it is possible to 'get changes for an item' and check whether a column of interest has changed. However, it seems like it would be costly to have the flow execute and run this test multiple times whilst a list item is being edited.

I would like to know is there a way to prevent multiple executions, perhaps by:

• configuring the SharePoint list so that traditional 'save/cancel' buttons are the only point-of-commit
• trigger conditions that can detect whether a particular column has changed
• some other approach, perhaps rethinking the list design or having a different trigger strategy (e.g. a scheduled sweep for particular column-level changes?)

Many thanks,

[Mart1 · Accepted solution]

I have just discovered that the trigger does not behave as I anticipated. It seems to poll for changed records rather than processing a queue of triggering events. Therefore, multiple intervening updates are not considered individual (multiple) trigger events; instead, the item having changed at all is the (single) trigger.

[Mart1]

This trigger behaviour presents challenges of its own, but eliminates the (perceived) problem that I raised this topic to solve.