Unanswered

“When an item is modified” trigger only runs with Split On enabled

(0) Share

Report

Posted on by CU16121557-0

Hi all,

I’m having an issue with a Power Automate flow using a SharePoint list, and I’m trying to understand whether this is expected behaviour or a known limitation.

What I’m trying to build

I have a SharePoint list where an item is reviewed and a Choice column is updated with one of three outcomes:

Rejected
Approved
Referred for further assessment

The flow is responsible for automatically updating the item status to match the selected outcome. The status is not edited manually.

Based on the selected outcome, the flow should:

Rejected
- Send an email back to the person who raised the item
- Automatically update the item status to Rejected
Approved
- Send an email to the next person who needs to sign off
- Automatically update the item status to Approved
Referred for further assessment
- Send an email to a different reviewer / assessment group
- Automatically update the item status to Further assessment required

In all cases:

Each email should be sent once only
The status update is part of the same flow
The flow should not loop or resend emails on subsequent edits

Trigger being used

SharePoint – When an item or a file is modified

Expected behaviour

Flow triggers once when the reviewer selects an outcome
One email is sent to the correct recipient based on the outcome
Item status automatically updates to match the outcome
Further edits should not retrigger the same email

Actual behaviour

If Split On is OFF and trigger conditions are used, the flow does not run at all
- No runs appear in run history
- No emails are sent
If Split On is OFF and no trigger conditions are used, the flow still does not run reliably

However:

If Split On is ON and all trigger conditions are removed, the flow does run
Emails are sent every few seconds, resulting in continuous email spam
This confirms the trigger is firing, but only behaves when Split On is enabled

Additional context

I have a separate flow that runs when an item is first submitted (using item creation), and that flow works reliably. The issues only occur when reacting to reviewer decisions using item modified.

Key issue

The trigger only fires reliably when Split On is enabled, even though it returns a single item
With Split On enabled, the flow loops uncontrollably
With Split On disabled, trigger conditions prevent the flow from firing at all

This makes it difficult to build a stable workflow that:

Reacts to a specific Choice value
Routes emails to different people depending on outcome
Automatically updates status
Avoids repeat notifications

Question

Is this:

A known issue or limitation with the “When an item or a file is modified” trigger?
Expected behaviour when using trigger conditions alongside automatic status updates?
A scenario where a different pattern (for example detecting field changes) is recommended?

Any guidance would be appreciated.

Categories:

Building flows

I have the same question (0)

All responses (2)

Answers (0)

Michael E. Gernaey 53,969 Moderator on at

Like (1)

Report
Copy link

Link copied!

Hi @CU16121557-0

This is because you are updating the same Item that you triggered from so you are breaking it. What is happening is expected behavior.

You should have split on (it's the best way to do it)

You also need to add a condition so that the flow doesn't actually DO anything else it meets the criteria you are referring too

If you update it over and over and over due to the infinite loop being caused it will do what you are saying.

Yes your other flow that makes absolute sense because create can only happen 1 time for each item, but modified happens every time.

So you trigger 1 time

You do an update

you make it trigger again

it updates again

and so on..

You need to add either a trigger condition or a literal Action Condition that checks whether or not the flow should do anything and if NOT then terminate the instance, don't let it run and update itself over and over.

If these suggestions help resolve your issue, Please consider Marking the answer as such and also maybe a like.

Thank you!
Sincerely, Michael Gernaey

Was this reply helpful? Yes No
CU16121557-0 5 on at

Like (0)

Report
Copy link

Link copied!

Hi Michael, thanks for your response! I just want to check my understanding in very simple terms.

For the first flow, it works reliably because it’s reacting to a clear one-off user action (submitting the item), so it’s like pressing a button , the flow runs once and stops.

For the second flow, the user manually selects a decision value, but the trigger is still effectively reacting to any change on the item. When the flow then updates the status, that counts as another modification, so the trigger fires again.

So even though the decision column and the status column are different, the trigger can’t tell the difference unless I explicitly check whether the decision field changed in that run, rather than just checking its current value.

Am I right in thinking that the correct pattern here is to let the trigger fire, then use change detection (for example “Get changes for an item”) to decide whether the flow should actually do anything?

I just want to make sure I’ve understood the behaviour properly so I’m designing the system the right way.

Thanks!

Was this reply helpful? Yes No