This trigger is extremely powerful, but it also introduces a subtle and dangerous behavior: recursive updates — meaning that every time the flow updates the same item that triggered it, the flow fires again, leading to infinite loops or trigger storms.
The Lifecycle of a SharePoint List Item in Power Automate — and How to Avoid Infinite Loops
1. Understanding the SharePoint–Power Automate Relationship
Power Automate integrates tightly with SharePoint Online. One of its most common triggers is:
“When an item is created or modified”
This trigger is extremely powerful, but it also introduces a subtle and dangerous behavior: recursive updates — meaning that every time the flow updates the same item that triggered it, the flow fires again, leading to infinite loops or trigger storms.
To understand how to avoid that, we must first analyze the lifecycle of an item in SharePoint.
2. The Lifecycle of a SharePoint Item
Every SharePoint list item passes through several internal states:
| Phase | Description | System Behavior |
|---|---|---|
| 1. Creation | A user, process, or API creates a new item. | The item receives an ID, Author, Created fields, and initial metadata. |
| 2. Initial Trigger | Power Automate flow with “When an item is created or modified” activates. | The flow reads item data and begins execution. |
| 3. Update Operation | The flow (or another process) modifies fields using Update item. | This counts as a modification event for SharePoint. |
| 4. Secondary Trigger | SharePoint notifies Power Automate of a new modification. | If the same flow is listening for “created or modified,” it runs again. |
| 5. Recursive Cycle | Each execution modifies the same item again. | The loop continues indefinitely until manually stopped or throttled. |
That’s the infinite trigger loop — the most common mistake in flows involving updates.
3. Why the Infinite Loop Happens
When Power Automate executes “Update item”, it calls the SharePoint REST API internally, marking the item as modified.
Since the trigger listens to all modifications, including those made by Power Automate itself, the flow immediately runs again.
There is no built-in mechanism to distinguish between “user updates” and “flow updates.”
That means your own flow can keep triggering itself indefinitely.
4. Why “When an item is created or modified” Is Dangerous
This trigger fires twice per lifecycle:
- Once when the item is created.
- Again every time it is changed — even by automation.
Unless you introduce complex conditional logic (e.g., checking editor name, version, or custom flags), the trigger will fire every single update, including those initiated by the flow itself.
This results in:
- Multiple flow runs per item.
- Loops consuming Power Automate quota.
- Throttling or blocking of the SharePoint connector.
- Delays and possible corruption of item data due to parallel updates.
5. The Safe and Recommended Pattern
The safest approach is to split creation and update logic into separate flows:
Flow A — Creation Flow (Recommended Trigger)
Trigger: “When an item is created”
Purpose: handle initialization logic (e.g., assign status, send notifications, set metadata).
Pattern:
- Start with When an item is created.
- Use
Update itemif needed to adjust fields (e.g., add an ID prefix, assign owner). - End. No recursive risk because the trigger never fires on modifications.
Flow B — Controlled Update Flow (Optional)
Trigger: “When an HTTP request is received” or a manual button.
Purpose: process updates safely through explicit calls.
Pattern:
- External process or Flow A calls this flow via HTTP.
- This flow performs
Update itemoperations. - Ends cleanly without re-triggering itself.
6. Conditional Update Strategy (If You Must Use “Created or Modified”)
In rare cases, you must use “When an item is created or modified” — for example, if user edits must trigger calculations.
Then, follow these safety rules:
| Safety Rule | Example Implementation |
|---|---|
| 1. Track Update Source | Create a field FlowUpdateFlag (Yes/No). Before updating an item, set FlowUpdateFlag = true. The trigger flow begins with a condition: “If FlowUpdateFlag = true, terminate flow and set flag = false.” |
| 2. Filter by Modified By | Add condition: “If Modified By equals [Flow Account] → Exit flow.” |
| 3. Use Delay or “Do Until” for stabilization | Wait 5–10 seconds after item creation before updating, allowing SharePoint to commit changes fully. |
| 4. Avoid nested updates | Batch multiple field updates into a single Update item action. |
| 5. Always use concurrency control | In flow settings → Turn off concurrency to prevent parallel updates. |
7. Practical Design Example
Scenario:
You need to set a default Status = “Pending” when an item is created, and later mark it as “Processed” once the system completes some checks.
✅ Correct Design:
| Step | Flow | Trigger | Key Actions |
|---|---|---|---|
| 1 | Flow A | When an item is created | Initialize Status = “Pending”. |
| 2 | Flow A | Delay Until Condition Met | Wait until related process finishes. |
| 3 | Flow A | Update item | Set Status = “Processed”. |
| 4 | Flow A | End | No loops triggered. |
8. Avoid Using “When an item is created or modified” for System Updates
It’s best practice to never use this trigger for system-driven updates.
System flows should use:
- “When an item is created” (for initialization).
- “When an HTTP request is received” (for triggered logic).
- “Manually trigger a flow” (for admin corrections).
- Scheduled flows (for periodic synchronization).
These methods break the recursive cycle and give you full control over execution.
9. Conclusion
The infinite loop problem is one of the most common mistakes in Power Automate–SharePoint integrations.
To avoid it:
- Do not use
Update iteminside flows triggered by “When an item is created or modified.” - Prefer using the creation trigger only, or separate your logic into distinct flows.
- If unavoidable, use flags, “Modified By” conditions, and concurrency control to stop recursive triggers.
This design pattern ensures stability, performance, and predictability in your automation architecture.
10. Quick Reference Summary
| Concept | Best Practice | Risk if Ignored |
|---|---|---|
| Trigger Type | Use “When an item is created” only | Flow loops indefinitely |
| Update Item Action | Only after creation or external trigger | Re-triggers flow |
| Conditional Flag | Use FlowUpdateFlag | Flow runs twice per update |
| Flow Separation | Split into creation and update flows | Hard to debug and maintain |
| Delay/Do Until | Stabilize after creation | May update incomplete data |
| Concurrency | Disable for critical flows | Parallel loops and collisions |
edvaldo b. guimarães filho 