The original AWB-EXP-001 edge tests found a duplicate problem that the main test did not reveal. A duplicate-client submission and an exact replay both created a second company and a second set of downstream onboarding artifacts. That happened even though the Make executions completed successfully.

This article reports a repair and retest of an inactive Implementation A v2 candidate using fixed synthetic inputs. It is not a production-agency result, and it does not establish general workflow reliability. The useful finding is narrower: a HubSpot uniqueness constraint, paired with a limited Make error route, suppressed the two retested duplicate cases before downstream work ran.

Why the original 19/19 result was not enough

The original main series had 19 valid runs, all successful. Those normal runs had not established duplicate safety: they did not prove what would happen if the same client identity arrived again or if a request was replayed.

The separate edge tests did exactly that. In duplicate-client, two payloads shared a client ID but had different company names. In repeat-submission, the same payload was sent again. Both cases originally produced duplicate companies and repeated tasks, emails, and calendar events. The earlier duplicate-records test documents those frozen pre-repair observations.

The first repair hypothesis did not solve the create race

My first repair hypothesis was to enable Make’s Process data in order setting. It serializes scenario runs, which is useful when arrival order needs to be controlled. But serialization alone did not prevent the second Create Company attempt.

The existing search at node 37 and client-ID storage at node 6 were both confirmed in the candidate configuration. That confirmation does not explain why the search-before-create design had failed in the observed immediate duplicate case. In particular, the evidence does not prove a HubSpot search or indexing cause, so I do not attribute the failure to indexing delay.

The safer conclusion was operational: search-before-create had not prevented the observed duplicate, so it needed a hard guard at the point of creation.

The repair: make client identity a HubSpot constraint

I added a dedicated HubSpot Company property, awb_client_id_unique (label: AWB Client ID Unique). It is a required-unique, single-line text property. At node 6, the Create Company module continues to store the incoming client_id in the existing AWB Client ID field and also writes that same value to AWB Client ID Unique.

That second mapping matters because it moves duplicate protection from a best-effort workflow decision to a HubSpot-enforced uniqueness constraint. A second Company creation carrying the same client ID is rejected by HubSpot.

The node 6 error handler is deliberately narrow. Its filter requires both of the following conditions:

  • Error.Message contains awb_client_id_unique
  • Error.Message contains already has that value

Only then does the route execute Skip 38. In other words, that expected unique-constraint rejection becomes a successful no-op. Other node 6 errors are not intentionally swallowed by this route and remain failures.

Retest 1: same client ID, changed company name

The duplicate-client retest sent two near-simultaneous submissions with the same client ID and different company names.

Submission Make result Operations Approximate duration
First full run Success 12 About 5 seconds
Duplicate run Success 3 Under 1 second

On the duplicate run, node 6 received the unique-value rejection, the filtered route ran Skip 38, and processing did not continue to node 20 or downstream modules. Manual UI review across HubSpot, Gmail, and Google Calendar found one Company, one Contact, four onboarding Tasks, one Welcome email, one Internal handoff email, and one Calendar event. The recorded classification is suppressed-as-no-op.

There is an important semantic limit. Arrival order was not guaranteed, and the surviving Company was the changed-company payload. This is first-arrival-wins, not update or reconciliation behavior: a later same-client-ID payload is discarded rather than merged into the existing record.

Retest 2: exact replay

For the replay retest, the exact same payload was sent once and then submitted again after eight seconds.

Submission Make result Operations Approximate duration
First run Success 12 About 5 seconds
Replay Success 3 Under 1 second

The replay followed the same node 6 unique-value-rejection and filtered Skip path, with no downstream continuation. Manual UI review found one Company, one Contact, four onboarding Tasks, one Welcome email, one Internal handoff email, and one Calendar event. The recorded classification is idempotent-no-op.

For this exact replay, the repair demonstrated the idempotency property that the original edge test lacked: repeating the tested input did not add another set of the reviewed artifacts.

What this repair does—and does not—promise

This is a constrained duplicate guard, not a general reliability result.

  • Two repaired edge cases do not establish general workflow reliability.
  • The cause of the original search-before-create failure was not proven.
  • A changed payload with the same client_id is discarded as a no-op; it is not merged, reconciled, or used to update the surviving record.
  • The result depends on the HubSpot unique property remaining the hard constraint and on node 6 receiving the incoming client_id in that field.
  • The Company, Contact, task, email, and event totals were manually reviewed in product UIs; they were not API-verified or automatically collected.

I also recorded roughly 1 minute 40 seconds for manual cleanup after the successful v2 tests. That is post-test cleanup time only. It is not the original edge-case recovery-time metric and should not be compared or equated with it.

For a workflow that must support client-data changes, the next design question is separate from duplicate suppression: whether an existing client should be updated, reconciled, queued for review, or rejected. That behavior needs an explicit design and its own tests.

If you want to build or test a similar automation, you can create a Make account. Affiliate disclosure: this Make link is an affiliate link, and Agency Workflow Bench may earn a commission at no additional cost to you.

Repair evidence and scope

This article draws its repair and retest claims from the committed Implementation A v2 evidence package. The retest result files preserve local test-artifact references and fingerprints, but no raw webhook payloads. They also record downstream totals as manual UI-review observations, not automated collection.

  • Repair configuration and diagnostic limit: benchmark/exp001-v2-repair/repair-config.json
  • Repair scope, semantics, and evidence notes: benchmark/exp001-v2-repair/README.md
  • Changed-payload duplicate-client retest: benchmark/exp001-v2-repair/results/duplicate-client.json
  • Exact repeat-submission retest: benchmark/exp001-v2-repair/results/repeat-submission.json