When automating SharePoint processes with Power Automate, one of the most critical design decisions is which trigger to start your flow.

Many users instinctively select “When an item is created or modified”, believing it offers flexibility — but in practice, it often causes unpredictable behavior, recursive loops, and data corruption.

Power Automate and SharePoint: Why You Should Always Use “When an Item Is Created”

1. Introduction

When automating SharePoint processes with Power Automate, one of the most critical design decisions is which trigger to start your flow.

In contrast, the trigger “When an item is created” is safer, cleaner, and more controllable.

This article explains in detail why the “created” trigger should be your default choice, and how to design stable flows that update items without risking infinite loops.

2. How the Triggers Work

Trigger	What It Does	Common Use
When an item is created	Fires once, immediately after a new SharePoint list item is saved for the first time.	Initialization of metadata, sending notifications, setting defaults.
When an item is created or modified	Fires every time an item is saved — both for new items and for any subsequent edit, even by Power Automate itself.	Rarely needed; should be used only for user-driven edits that require extra logic.

The difference seems small but has huge implications.

3. The Problem with “Created or Modified”

When a flow that uses this trigger updates the same item using “Update item”, SharePoint records that as a modification.
This means the trigger fires again, restarting the flow.

So the flow:

Runs because an item was created or changed.
Executes an “Update item” action.
That update counts as a modification.
The trigger fires again.
The flow runs again.
And again.
Forever.

This is called a self-triggering infinite loop.

Example:

A flow that calculates a “Total Cost” column, then updates the same item with that value, ends up triggering itself infinitely unless you manually cancel all runs.

4. Technical Consequences of the Loop

Consequence	Description
Infinite execution	Each update re-triggers the same flow instance.
System throttling	SharePoint connector may hit service limits.
Run history explosion	Thousands of runs created in minutes.
Field overwrites	Values may be updated mid-process, causing data loss.
Automation failure	The flow stops responding or is suspended.

This is one of the most common mistakes in SharePoint automation and is responsible for many failed or throttled environments.

5. Why “When an Item Is Created” Is the Safe Default

The “created” trigger only fires once, at the very start of the item’s lifecycle.
That means:

✅ No recursive loops — because updates that occur later don’t re-trigger the flow.
✅ Predictable timing — you control exactly when initialization happens.
✅ Simpler logic — no need to check for flags or modified-by conditions.
✅ Stable audit trails — your flow updates happen once, cleanly recorded.
✅ Easier troubleshooting — one item, one run.

6. Recommended Pattern: Controlled Lifecycle Flow

You can design a single, stable flow that handles the entire lifecycle of an item using only “When an item is created.”

Step-by-step pattern:

Step	Action	Purpose
1. Trigger	Use When an item is created	Start only once when the item is new.
2. Initialization	Set default fields (Status = “Pending”, AssignedTo = “System”)	Prepare the record for later updates.
3. Processing / Wait	Use Delay Until or Do Until to wait for external data or approval	Avoid firing new triggers.
4. Update Item	Safely call `Update item` because this trigger won’t fire again	Apply calculated results or status changes.
5. End Flow	Complete execution cleanly	No risk of recursion.

This pattern ensures one single, predictable run per item.

7. Example: Safe Flow Design

Scenario

You need to create a project record, then automatically calculate a start date and assign a project number.

Flow Configuration

Trigger: When an item is created.
Action 1: Initialize variable ProjectNumber.
Action 2: Calculate start date.
Action 3: Update item with ProjectNumber and StartDate.
Action 4: Send Teams or email notification.
End.

Result:
The flow runs once, updates the new record, and stops — with zero loops.

8. What if You Must Handle Modifications?

If your business case truly requires responding to item changes, do not mix creation and modification in the same flow.

Instead, create two separate flows:

Flow	Trigger	Purpose
Flow A	When an item is created	Initialize item, set metadata, and handle first updates.
Flow B	When an item is modified	Only respond to user edits (never system edits). Add conditions to avoid loops.

In Flow B, always add:

A condition checking “Modified by” ≠ Flow Account, or
A custom Boolean flag (FlowUpdated) set to true/false around updates.

These safety checks prevent self-triggering behavior.

9. Governance and Best Practices

Area	Recommendation
Trigger selection	Always prefer “When an item is created”.
Update control	Use “Update item” only after initial creation.
Flow separation	Keep creation and modification flows independent.
Concurrency	Turn off parallel runs for stability.
Field flags	If needed, use a “FlowUpdated” column to block recursion.
Testing	Always monitor first 5–10 runs in the Power Automate portal to confirm no repeated triggers.

10. Key Takeaways

Never use “When an item is created or modified” unless absolutely necessary.
Prefer “When an item is created” — it’s stable, predictable, and loop-free.
If modifications are required, isolate that logic in a separate flow with strict filters.
Recursive updates consume Power Automate runs, slow your environment, and risk data integrity.
A clean design always starts at creation and flows forward, not back into itself.

11. Summary Table

Aspect	“When an item is created”	“When an item is created or modified”
Execution Frequency	Once per new item	Every change (including flow updates)
Risk of Loops	None	Very high
Ideal Use Case	Initialization, setup, notifications	User edits that require logic
Maintenance Overhead	Low	High
Recommended?	✅ Yes – Always use for automation	⚠️ Use only if absolutely required

12. Conclusion

The simplest and most robust automation strategy in Power Automate is to start with creation.
Every new SharePoint item has a clear lifecycle: creation → processing → completion.
You can safely handle all logic inside a single “When an item is created” flow — without recursion, without duplicated runs, and with total control.

Designing this way ensures that your flows are stable, maintainable, and future-proof, no matter how complex your SharePoint solutions become.