Avoiding duplicate deployments
One draft, one workflow: how retries resume instead of duplicating, and how to adopt a workflow n8n already has.
Why duplicates happen
A duplicate is created when a deploy is retried without knowing the first attempt already succeeded — typically after a failure in the save step that follows creation. The workflow exists on n8n, but the app never recorded its ID.
Let the retry resume
Every deploy runs under a stable per-draft attempt that stores the created ID the moment n8n returns it. Retrying the same draft verifies that ID on your instance and links it — creating a second workflow is skipped by design. If the dialog shows an n8n ID after a failure, that ID already exists: do not deploy fresh around it.
Adopt with Link existing
For workflows created before attempt tracking (or linked from another angle), the deploy error box offers Link existing: paste the n8n workflow ID to verify it, read it back, and attach it to the draft. Verify first — linking checks the ID exists before touching anything.
Rule of thumb: check n8n for the workflow before every retry. If it is there, link or resume — never re-create.
Next guide
From AI draft to tested automation: a complete pass
Questions? Contact Support.