I expected Make’s Process data in order setting to be enough to keep a duplicate client submission from reaching a second Company creation. In this tested onboarding workflow, it was not. The repaired evidence shows that a second Create Company attempt still reached node 6, even with that setting enabled.

That does not make a general claim about Make, HubSpot, or every serial workflow. It is a narrower result from an isolated Implementation A v2 candidate tested with fixed synthetic inputs.

What I expected

The original main series had 19 valid, successful runs. Those normal inputs did not establish duplicate safety, so I separately tested two ways an identity could arrive again: the same client_id with a changed company name, and an exact replay.

Before the repair, both edge cases created a second Company and another set of downstream onboarding artifacts. The changed-identity case and replay are different input semantics, but neither was safely handled by the original workflow. The full pre-repair observations are covered in the duplicate-records test.

What actually happened

I enabled Process data in order in the v2 candidate. The candidate also retained the existing search-before-create design. In the changed-payload retest, however, the second submission still made it to node 6, Create a Company. It received a duplicate-value rejection there.

So sequential processing did not, by itself, stop the second creation attempt in this workflow. The evidence establishes that observed path, not why the earlier search-before-create decision failed. In particular, it does not establish HubSpot indexing or eventual consistency as the cause.

What Process data in order did—and did not establish

The setting serializes scenario processing; in this test it did not replace a duplicate constraint at the Company-creation boundary. It may have controlled the order in which the runs were processed, but the retest did not show it preventing the later request from attempting node 6.

That distinction mattered because, if duplicate creation succeeds, downstream onboarding work can continue. This tested workflow therefore required a hard duplicate guard at the creation boundary.

The hard guard that fixed the tested case

The repair made HubSpot enforce the identity. A unique Company property, awb_client_id_unique, received the incoming client_id at node 6. When a second Company creation used the same value, HubSpot rejected it.

The node 6 error route treated only that expected rejection as a no-op. It ran Skip 38 only when the error message contained both awb_client_id_unique and already has that value. Other node 6 errors were not included in that route, so they remained failures rather than being broadly suppressed.

Retest results

In the changed-company duplicate retest and the exact replay retest, the first run used 12 operations. Each later duplicate/replay run stopped after 3 operations, following the node 6 unique-value rejection and filtered Skip path without continuing downstream.

Manual UI review across HubSpot, Gmail, and Google Calendar found the same final state for each retest: 1 Company, 1 Contact, 4 onboarding tasks, 1 welcome email, 1 internal handoff email, and 1 kickoff calendar event. The changed-payload duplicate was classified as suppressed-as-no-op; the exact replay was classified as idempotent-no-op.

This is first-arrival-wins / no-op behavior, not merge or update behavior. A later payload with the same client ID is discarded rather than reconciled into the surviving Company.

What this test does not prove

  • It does not show that Process data in order never prevents duplicates.
  • It does not show that Make is not idempotent or that HubSpot always has an indexing or eventual-consistency problem.
  • It does not establish general workflow reliability from two repaired edge cases.
  • The downstream totals were manual UI-review observations, not API-verified or automatically collected evidence.

For the broader repair design, retest details, and the original 19/19 limit, read How I Fixed Duplicate Records in a Make + HubSpot Onboarding Workflow.

Evidence used

This article relies on the frozen original Article 4 context and the committed Implementation A v2 repair package: benchmark/exp001-v2-repair/repair-config.json, benchmark/exp001-v2-repair/results/duplicate-client.json, and benchmark/exp001-v2-repair/results/repeat-submission.json. No new experiment or external-service action was performed.