Design duplicate prevention around the business action, not merely around whether a workflow has run before. Define a stable action identity, evidence of prior completion and one owner responsible for deciding whether another attempt is permitted.
Distinguish repeats from legitimate new work
Two notices about the same approval may represent one business event. Two separately approved revisions may represent different work. Your design must tell them apart without relying only on arrival time.
n8n's documented model is a collection of connected nodes with execution-history context. That does not establish automatic deduplication or exactly-once business effects. Treat duplicate prevention as a process requirement that needs implementation verification.
A run record can help an investigation, but “the workflow started” is not equivalent to “the external action completed.”
Fill in an idempotency design card
Use this editorial card for each consequential action:
- Action identity: which stable fields distinguish one intended action?
- Repeat definition: which differences should not create new work?
- Completion evidence: what external reference proves the action happened?
- In-progress owner: who controls a second arrival while the first remains unresolved?
- Uncertain outcome: how will someone check an action that may have completed?
- Retention decision: how long must prior-action evidence remain useful?
- Legitimate replay: who may authorise a new attempt and why?
Ask whether the eventual destination offers a suitable duplicate-control mechanism; do not assume it does. Also ask how simultaneous arrivals will be handled rather than designing only for sequential repeats.
Evaluate a synthetic instruction sequence
In a hypothetical Surat workshop, approved request R-52 revision 3 should create one production instruction. The proposed identity is R-52 plus revision 3 plus “production instruction.”
Evaluate these arrivals:
- The first event arrives: eligible for one action.
- An identical event arrives a minute later: check completion evidence, not merely its timestamp.
- Another copy arrives while the first action is unresolved: hold under the designated owner.
- Revision 4 receives separate approval: evaluate as potentially new work.
- The instruction exists, but completion recording failed: reconcile the existing instruction instead of blindly creating another.
The example passes only if every repeat has an explainable outcome and unresolved work cannot silently acquire a second owner.
Stop when identity is unstable
Stop if the proposed key changes with formatting, delivery time or an unrelated edit. Next, agree stable identity and reconciliation rules with the person responsible for the destination process.
For procurement, check the automation catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or duplicate-prevention guarantees.
Sources and scope
Source material checked 29 October 2026; features/policies may change. n8n workflow documentation establishes the workflow model and execution context. The design card and synthetic repeat cases are editorial advice, not documented deduplication capabilities.