The repaired duplicate guard in this tested Make + HubSpot onboarding workflow produced two distinct outcomes: an exact replay became an idempotent-no-op, while a changed same-identity duplicate was suppressed-as-no-op. The former is useful idempotent behavior for a replay; the latter is not a strategy for merging or updating client data.

The guard was HubSpot’s unique awb_client_id_unique Company property. At node 6, Create a Company, a later matching value was rejected; the filtered duplicate-only error route sent that expected rejection to Skip 38. The later run stopped after 3 operations and did not continue to the onboarding modules.

The behavior I ended up with

The observed behavior was first-arrival-wins / later-duplicate no-op. More precisely, the first Company creation that HubSpot accepted became the surviving record, while later same-identity creation attempts were suppressed as no-ops before downstream onboarding work.

The retest did not establish transport-level arrival ordering. It does show that the first accepted Company creation survived and that later same-identity creation attempts became no-ops under the unique constraint. This is a narrow result from the repaired Implementation A v2 workflow, not a universal definition of how Make or HubSpot handle duplicates.

What happened on an exact replay

In the repeat-submission retest, the exact same payload was submitted and then repeated after eight seconds. The seed run succeeded with 12 operations. The replay reached node 6, received the unique-value rejection, followed the filtered route to Skip 38, and completed after 3 operations with no downstream continuation.

That result was classified as idempotent-no-op: repeating the tested input did not create another reviewed set of onboarding artifacts. Manual UI review found one Company, one Contact, four onboarding tasks, one welcome email, one internal handoff email, and one kickoff calendar event.

What happened when the same client ID arrived with a changed company name

The duplicate-client retest used two near-simultaneous submissions with the same client ID and different company names. The first full run used 12 operations; the duplicate run reached node 6, was rejected by the uniqueness guard, took the filtered Skip 38 route, and stopped after 3 operations.

The later payload was suppressed as a no-op. Its recorded classification was suppressed-as-no-op. The retest showed no continuation to node 20 or the downstream modules, and manual UI review found the same single set of onboarding artifacts. It did not establish transport-level arrival ordering.

Crucially, this does not mean the later company name was merged into the surviving Company. The observed behavior was no update, no field reconciliation, and no merge of a later duplicate payload.

Why this is first-arrival-wins

First-arrival-wins describes the observed decision rule in effect here: an identity gets one accepted Company creation, and later same-identity create attempts become no-ops. It does not establish transport-level arrival ordering. It protects the workflow from making a second Company and a second downstream onboarding set.

For the exact replay, that rule also delivered idempotency in the tested case: resubmitting an unchanged request did not add a second result. Idempotent no-op therefore describes the replay outcome; first-arrival-wins describes how the duplicate identity was resolved in this workflow.

Why this is not merge/update

A merge or update design would need an explicit decision about what a later payload may change, how conflicting values are selected, and whether the existing Company or related onboarding data should be revised. None of that happened in the repaired retests.

The duplicate guard only rejected a second Company creation with the same unique client ID. It did not compare fields, reconcile company names, or apply the later payload to the existing Company. Calling this an update strategy would overstate the evidence.

When this behavior is useful—and when it is not

As a design interpretation, first-arrival-wins can fit an onboarding workflow when duplicate submissions must not alter an already-created record or trigger another onboarding sequence. It may be a poor fit when later submissions can contain legitimate corrections or expected updates. In that case, the workflow needs separately designed and tested update, reconciliation, or review logic.

Limitations

  • The downstream totals were manual UI-review evidence across HubSpot, Gmail, and Google Calendar; they were not API-verified or automatically collected.
  • These two repaired edge cases do not establish general workflow reliability.
  • The retest does not prove why the earlier search-before-create design failed, nor does it establish a general Make or HubSpot duplicate-handling rule.

For the complete repair, retest setup, and evidence scope, read How I Fixed Duplicate Records in a Make + HubSpot Onboarding Workflow. For the separate finding that sequential scenario processing did not itself prevent the second creation attempt, read Why Process Data in Order Didn’t Stop My Make + HubSpot Duplicate.

Evidence used

This article is based on the frozen repair configuration and results: benchmark/exp001-v2-repair/repair-config.json, benchmark/exp001-v2-repair/results/duplicate-client.json, and benchmark/exp001-v2-repair/results/repeat-submission.json, with context from the full repair article. No new experiment or external-service action was performed.