Prevent duplicate orders in Make: a practical workflow

Prevent duplicate orders in Make by tracing a stable source identifier and checking what happened in the destination. Use clear outcome states and a tested recovery process rather than assuming one setting guarantees exactly-once work.

Why do duplicate orders appear in Make?

To prevent duplicate orders in Make, first identify where the repeated business action begins. Make connects applications through scenarios, which are the workflows you configure. A repeated source notification, two workflows writing the same order or a retry after an uncertain result can all require different responses. Do not assume the final create module is the only place to investigate.

Imagine a hypothetical independent retailer copying new orders into another business system. The same source notification arrives twice and two destination records appear. This is an illustrative situation, not a report about a real shop or a tested Make scenario.

Distinguish duplicate order records from duplicate messages and duplicate stock actions. Preventing one does not prove the others are safe. A customer can also place two legitimate orders. Collapsing them into one is a different error. Map the affected action before changing the workflow.

Start by tracing a single source order identifier through incoming data, Make execution and the destination application. A successful execution indicator is not evidence that every business effect happened exactly once. The planning principles in recurring billing automation are useful context, but this guide focuses specifically on duplicate order effects.

Collect evidence before changing the scenario

Choose one affected order and record its source identifier. Compare the incoming events with the destination records. Execution count alone is insufficient because a single execution can produce more than one business effect. Keep the evidence tied to the actual order rather than a screenshot showing a generic error.

An external write can succeed while its response fails to reach the workflow. That is a possibility to account for in distributed work, not a claim about every error in a particular module. Before repeating a create step, inspect the destination to establish what happened.

Agree on the meaning of duplicate. A redelivered event, an order status change and a genuinely new order are different inputs. The team should know which result each one is allowed to produce. If you also automate order taking through a bot, include that writing path in the investigation.

Use a stable identifier for the business action

A stable key lets the system recognise the same work when it returns. The source order identifier is a useful starting point; include the source shop when several shops feed the workflow. A label such as shop-a:order-123:create is a proposed naming convention, not a required Make format.

Generating a fresh random identifier for each attempt defeats recognition of a repeated order. Customer email alone is also unsuitable because one person may place multiple valid orders. A combination of date and amount can accidentally merge unrelated transactions. Preserve the actual source identifier.

Define the action as well as the order. Creating an order and updating its status should not blindly share a rule that means ignore this order forever. Otherwise, a legitimate later update can be blocked. Idempotency means repeating the same intended action without creating an additional business effect.

Document where the key is stored and how it relates to the destination record. The destination identifier helps a reviewer reconcile an uncertain result. Do not redesign existing records in bulk merely to follow an example from an article. Establish a separate plan and test scope for any migration.

A separate notification action may need its own control. The planning questions in sales follow-up automation illustrate why sending a message should not be treated as identical to writing an order.

Store outcome state, not just a seen flag

Make's Data Store retains information across executions. Check the Existence of a Record checks a key; Add/Replace a Record can add a keyed record and raises an error for an existing key when overwrite is disabled. These documented behaviours are described in the Data Store guide.

A key exists is different from the order was successfully created. Suggested operational states include started, destination confirmed and outcome unknown. These are your design choices, not built-in order states supplied by Make. Keep a destination record identifier where the process needs one.

Writing a marker before the external action and calling it complete can lose work if the action fails. Writing the marker only afterwards leaves a possible failure between the external result and the marker. Do not describe the Data Store write and another application's action as one indivisible transaction.

A simple check-then-create flow can race when two executions run at the same time. Both may observe that a record is absent. Module names alone do not prove that this risk has been removed. If several workflows or systems can write the same order, have the technical owner verify the destination's stable-key and uniqueness behaviour as well.

Understand the scope of ordered processing

Webhooks send data into Make when an external event occurs. Make documents parallel processing as the default for instant webhook scenarios. Process data in order makes a scenario wait for the previous execution to finish. The current setting and behaviour are in Make's webhook documentation.

Ordered processing can help with overlap in that scenario, but it does not prevent the same event from arriving again tomorrow. It does not automatically control a different scenario or a write outside Make. Slow work can also make later items wait. Test both the benefit and the delay for your process.

Give order creation a clear owner. List every application, automation and manual route that can perform the action. Turning on one setting in one workflow cannot establish a guarantee across those separate writers. The operational discipline discussed in backup automation also matters when planning changes, but a backup is not a duplicate-prevention control.

For payment or inventory effects, ask the technical owner to review the design before enabling a new recovery path. This is a practical investigation guide, not a production-ready scenario recipe. A stable key, clear ownership, confirmed destination result and recovery procedure must be considered together.

Reconcile the destination before retrying

Make documents incomplete execution storage as disabled by default. Enabling Store incomplete executions allows unfinished runs to be retained, with supported automatic retries, Retry error handling or manual resolution. See the incomplete executions guide for the actual conditions.

Before retrying, check whether the destination order already exists. If it does, identify the remaining work rather than creating another record. If the outcome is unknown, do not label it complete or failed merely to clear a queue. Assign a reviewer to connect the destination evidence with the previous attempt.

Do not delete stored keys simply to make the workflow run again. That can turn previously handled work into apparently new work. Likewise, do not suppress every error as though it were a duplicate. A storage or connection problem requires a different response.

Track notification effects separately. Re-running the whole scenario might send another message even when order creation is controlled. The same principle matters for recovery emails and other customer communication. A single green status should not hide which actions are still uncertain.

Test repeated inputs and uncertain outcomes

Use test orders first. Deliver the same source identifier twice, then verify that two genuinely different orders still produce separate records. Test a status update separately. Include the case where a destination result exists but the workflow did not receive confirmation.

• Does the same order and action avoid a second destination record?
• Do two orders from the same customer remain separate?
• Can a legitimate status update continue?
• Is recovery clear when the external outcome is uncertain?
• Are message and inventory effects checked independently?
• Does someone own unresolved work?

This is a proposed acceptance checklist, not a statement that these tests have already passed. Record observed outcomes in your own system. One successful example does not establish an exactly-once guarantee for every possible failure. Revisit the checks when another writer or module is added.

Monitor incomplete work alongside successful runs. Reconcile source and destination counts using the same business definition. If you use a spreadsheet workflow for operational review, do not treat the sheet as proof that the external action succeeded. Base the conclusion on destination evidence.