Successful Make executions still left duplicate records and onboarding work in two separate AWB-EXP-001 edge tests. In the frozen Implementation A observations, both duplicate-client and repeat-submission have the outcome duplicated. The concrete problem was broader than an extra CRM company: tasks, emails, and kickoff events were also repeated.
This was a fixed synthetic onboarding benchmark using Make, HubSpot Free, Gmail, and Google Calendar, not a live agency deployment. The first experiment report covers the overall setup and main test. Here, the question is narrower: what happened when the workflow received the same client identity again?
Two ways to submit the same client again
These tests answer different questions. A changed company name tests handling of an existing identity with updated information. An identical replay tests whether repeating an input creates unwanted additional outputs—idempotency in this workflow.
| Test | What was submitted | Frozen outcome |
|---|---|---|
duplicate-client |
A seed payload, then the same client_id with only company_name changed |
duplicated |
repeat-submission |
Exactly identical input twice, with matching canonical payload SHA-256 digests | duplicated |
duplicate-client: same identity, changed company name
The valid case is edge-duplicate-client-20260921-r3-fix. Its submission record shows that only company_name differs between the two payloads; client_id and the remaining fields stay the same. This was deliberately not an exact replay.
The structured observation records both submissions completing successfully in Make. Across the pair, it records two HubSpot company records, one shared contact, eight onboarding tasks, two welcome emails, two internal handoff emails, and two kickoff calendar events. The expected behavior was a safe update or rejection without duplicated client or downstream artifacts. The recorded outcome is therefore duplicated.
The evidence manifest also indexes retained HubSpot, Gmail, and Google Calendar images supporting duplicate artifacts for this case. The full counts above come from the structured observation. Earlier duplicate-client attempts are preserved separately as invalid and non-counting; they are not additional valid results.
repeat-submission: exactly the same input twice
The separate case edge-repeat-submission-20260921 sent the exact same payload twice. Both payload objects and their canonical SHA-256 digests match in the submission record. Unlike the changed-name test, there was no input update to handle.
Both Make executions completed successfully. The structured manual observation records two HubSpot company records, one shared contact, eight onboarding tasks, two welcome emails, two internal handoff emails, and two kickoff calendar events across the pair. Its expected behavior was no unintended second client or onboarding artifact set. Its recorded outcome is duplicated: this replay did not behave idempotently.
The repeat-submission downstream duplicate counts rest only on the structured manual observation. No downstream vendor screenshot exists in the retained evidence for this case. The saved Make image supports only the two successful executions; it does not prove the downstream counts. The evidence-pack README and manifest explicitly state that limitation.
In both tests, the contact was shared. Describing these results as duplicate contacts would misstate the record. The observed problem was duplicate companies and additional downstream work.
Execution success did not establish duplicate-safe behavior
The freeze defines technical completion as Make finishing without an unhandled module error. Benchmark success requires checking the required outputs as well, including the absence of unintended duplicates. These edge observations demonstrate why the distinction matters: an execution can finish successfully while leaving an unwanted second set of artifacts.
The edge tests are separate from the valid main runs. For the broader interpretation of that main-test result, see why 19/19 successful runs did not prove reliability. Neither these two edge cases nor the main series establishes a general duplicate rate for Make, HubSpot, or agency operations.
What the record says about duplicate handling—and what it cannot explain
The frozen design stores the benchmark client_id in the HubSpot company property awb_client_id. It describes an exact-equality search before company creation and stopping downstream creation if a matching company exists. That is the intended AWB-EXP-001 workflow-level duplicate handling. The observed duplicates show that the intended outcome was not achieved in these cases; the design description is not proof that the guard worked.
This workflow-level rule must be distinguished from HubSpot native deduplication. These records do not establish the scope or behavior of HubSpot’s native deduplication features. This article makes no general vendor-feature claim and does not attribute the duplicates to a Make or HubSpot product defect. The retained observations establish outputs, not the internal cause of the discrepancy between design and behavior.
Next experiment: Implementation A v2
The following are untested next-step hypotheses, not demonstrated fixes:
- Inspect and test search-before-create using a stable unique identifier such as the intended
awb_client_id. Because the freeze already describes this lookup, merely adding a step with that name is not evidence of a remedy. - Define and test create-versus-update routing for an existing identity with changed information, including what should happen to tasks, emails, and calendar events.
- Consider an explicit replay/idempotency guard for identical submissions and test whether it prevents unintended additional outputs.
After implementing a candidate fix in Implementation A v2, I would rerun the same duplicate-client and repeat-submission tests: first the same ID with a changed company name, then an exact replay. I would compare the observed CRM and downstream outputs with each test’s expected behavior, and retain downstream vendor evidence for the replay case as well as structured observations. No v2 fix or rerun is reported here, and none of these hypotheses has established effectiveness in this frozen record.
The site’s methodology includes repeated testing and recovery from failures. For this duplicate-records issue, the next useful evidence would be whether a revised workflow meets those same expectations when an identity or submission appears again.
Build or test a similar Make automation. Affiliate disclosure: this is an affiliate link; Agency Workflow Bench may earn a commission at no additional cost to the reader.
Frozen sources and evidence limits
All experimental claims above use the retained repository artifacts below. These are repository paths, not public screenshot links. No new experiment or vendor-feature verification is included.
- Changed-name inputs:
benchmark/exp001/results/edge/submissions/edge-duplicate-client-20260921-r3-fix/duplicate-client.json - Changed-name outcome and counts:
benchmark/exp001/results/edge/observations/edge-duplicate-client-20260921-r3-fix/duplicate-client.json - Identical replay inputs and matching digests:
benchmark/exp001/results/edge/submissions/edge-repeat-submission-20260921/repeat-submission.json - Replay outcome and manually observed counts:
benchmark/exp001/results/edge/observations/edge-repeat-submission-20260921/repeat-submission.json - Image scope and replay limitation:
benchmark/exp001/evidence/manifest.jsonandbenchmark/exp001/evidence/edge/edge-repeat-submission-20260921/README.txt - Intended duplicate guard and completion criteria:
benchmark/exp001/implementation-a-freeze.md - Excluded attempts:
benchmark/exp001/results/edge/invalid-attempts.json - Separation of main and edge results:
benchmark/exp001/results/implementation-a-summary.md