Design idempotent flows to prevent duplicate processing

Triggers fire twice. Retries happen. Concurrency exists.

That’s how you end up with duplicate records, double emails, or repeated approvals.

Idempotent flows fix this by guaranteeing that each business event is processed only once, even if the flow is triggered multiple times.

The core idea

Claim the event before doing any real work. If it’s already claimed, stop the flow.

Example: avoid duplicate invoice creation

Scenario

A flow triggers when a new order is created. Due to retries or parallel runs, the same order may trigger the flow more than once.

Goal

Ensure each order is processed only once.

The pattern

1. Choose a unique business key
   Something that uniquely identifies the event, for example:
   • OrderId
   • MessageId
2. Create a lightweight ProcessedEvents store
   Dataverse, SharePoint, or SQL with:
   • UniqueKey
   • ProcessedOn

3. First action = claim the event
   Create (or upsert) a row using the unique key.

   ✅ Success → first time processing
   ❌ Duplicate key → already processed

4. Handle duplicates gracefully
   On the duplicate path (Configure run after):
   • Terminate the flow early
   • No retries. No side effects.

This is a standard event-driven architecture pattern — applied in Power Automate.

Try this now

• Pick a flow that must never run twice for the same item
• Identify a stable business key
• Add a claim step as the first action
• Terminate immediately if the key already exists

💡 Tip

Idempotency is much easier to design upfront than to debug later. Once you use it once, you’ll start using it everywhere.