When a Form Submission Runs Twice, Your No-Code Workflow Needs a Duplicate Check

A customer completes your enquiry form once. Your automation creates two records, sends two welcome messages, and assigns the same request to different colleagues. Removing the extra row fixes the visible mess, but the workflow can do it again with the next repeated event.

The useful question is not simply whether the form contains repeated information. It is whether the automation is processing the same business event more than once. Designing around that distinction helps you protect legitimate repeat customers while handling retries deliberately.

Define the event that should happen once

Write a sentence describing the intended outcome: “Each submitted enquiry should create one intake record.” That is more precise than “Never create duplicate customers.” One customer may send several valid enquiries, and each may need its own record.

Use a stable submission identifier supplied by the form system when one is available. Carry it through the workflow and save it with the destination record. An email address identifies a contact, not necessarily an enquiry. A timestamp invented during each automation run changes on every retry and cannot reliably identify the original event.

Consider updates separately. A corrected address on an existing request might need to update that request, while a new purchase from the same person deserves a new transaction. Document those rules before adding a filter that discards anything with a familiar name.

Find where the repetition begins

Inspect the workflow’s run history using a test submission. Compare the incoming event identifiers, trigger times, and destination records. Look for multiple enabled workflows watching the same form, manual reruns, repeated deliveries, and steps that succeeded before a later step failed.

Do not assume the platform provides one universal duplicate shield. Zapier documents different behavior for polling triggers, instant triggers, and actions. Its polling deduplication operates within a particular Zap; two Zaps listening to the same trigger can both run. The destination app also influences what repeated create actions do.

Keep the investigation concrete. If there is one workflow run but two emails, examine the steps and destination behavior. If there are two runs carrying the same submission identifier, examine delivery and retry handling. Those situations call for different changes.

Put the check before the consequential action

A basic design looks for an existing intake record using the submission identifier. If it finds one, it follows the defined repeat-event path. If it finds none, it creates the record with that identifier. This can be useful, but a simple search followed by creation is not a complete concurrency guarantee.

Two runs can search at nearly the same moment, both find nothing, and both create a record. For stronger protection, use a destination that can enforce uniqueness or an operation that handles finding and creating as one protected action. Confirm what the actual connector supports instead of inferring protection from its label.

Where the destination supports idempotency keys, repeated attempts can refer to the same intended operation. Stripe documents this approach for its API, including limits and different behaviors across API versions. A visual workflow only benefits if its action exposes and correctly passes the supported key.

Remember that each side effect needs attention

A single intake record does not prove that only one message was sent. Imagine a run that creates the record, sends a welcome email, and then fails while recording completion. Restarting everything may send the email again even though the record check works.

Track the meaningful stages separately, such as record created, assignment completed, and message confirmed. Save destination identifiers when available. If a timeout leaves the outcome uncertain, inspect the destination before repeating an action that would bother a customer or move money.

There can be an awkward gap between an action succeeding and your workflow recording that success. When the service offers no reliable deduplication or outcome lookup, route ambiguous cases for review. A checkbox called “sent” cannot by itself guarantee exactly one delivery.

Test the rule with deliberate repetition

Use fictional data and a test destination. Check more than a single successful run:

• Deliver the same submission identifier twice.
• Submit a new enquiry from the same email address.
• Change an allowed field on an existing enquiry.
• Retry after a later step fails.
• Where supported, test two near-simultaneous deliveries.

For each case, inspect both the records and the outward actions. Define the expected result before testing so that a quiet workflow is not mistaken for a correct one; it may have discarded valid work.

Leave a short note explaining the event identifier, duplicate rule, retry behavior, and unresolved cases. The person maintaining the workflow should be able to tell whether a repeated submission was ignored, updated, completed, or held for review. That explanation is part of the automation’s design.