Cloning a Make scenario sounds like it should be a quick way to reuse a workflow. The practical uncertainty is what comes along for the ride: do the connections still work, does the webhook need replacing, and will every module need to be repaired before the clone can run?
I tested one immutable source scenario cloned into a new candidate in the same Make team. The narrow result: the clone reused its existing accounts/connections, a fresh webhook was created for the candidate, and one synthetic client-onboarding submission completed end to end with zero Make UI module reconfigurations.
That is useful evidence for this workflow and clone context. It is not a promise that every Make scenario, team boundary, or connection type behaves the same way.
What I tested
The source scenario was kept immutable throughout. I made a same-team clone with no semantic changes: zero requested and zero verified semantic transformations. Structural verification and the preflight checks both passed.
The candidate began inactive. Its existing same-team accounts/connections were reused, but I did not reuse the source webhook: a fresh candidate webhook was created. Before the run, the Make, HubSpot, Gmail, and Google Calendar observers were all ready.
This matters because “the clone exists” is not the same as “the cloned workflow can still complete its real path.” The synthetic onboarding was expected to create CRM records and four tasks, send a welcome email and an internal handoff, and create a kickoff event—the same general workflow area covered in the earlier Make + HubSpot onboarding test.
The one-run result
I activated the candidate and submitted exactly one synthetic fixture after explicit send approval.
The send status was SENT; there was no retry.
The API observer then reached a full 7/7 verified result:
| Downstream target | Result |
|---|---|
| Make execution | Verified by API |
| HubSpot company | Verified by API |
| HubSpot contact | Verified by API |
| HubSpot onboarding tasks | Verified by API; exactly 4 expected tasks |
| Gmail welcome message | Verified by API |
| Gmail internal handoff | Verified by API |
| Google Calendar kickoff | Verified by API |
No manual Make UI module reconfiguration occurred after cloning. For this same-team scenario, reusing the existing connections and attaching a fresh candidate webhook was enough in this run for the clone, with zero semantic workflow mutations, to complete one synthetic onboarding.
Webhooks and connections: the practical takeaway
The successful path was not “clone it and keep the old webhook.” The source remained untouched, and the candidate received a fresh webhook. The existing same-team accounts/connections were reused; the webhook was candidate-specific.
If you are cloning a similar scenario inside one team, treat the webhook as an attachment to verify or create for the candidate, rather than assuming the source webhook has been carried forward safely. Then test the actual downstream path, not merely whether the scenario opens without errors.
Timing and cleanup
These are wall-clock timings, not active-human-work measurements:
- Candidate-creation start to full API verification: 4m00s.
- Candidate-creation start to cleanup completion: 7m39s.
- Manual cleanup duration: 1m45s.
Active human time was not independently measured, so the 7m39s total should not be read as hands-on setup time.
After the run, the candidate was deactivated. The provenance-bound cleanup inventory covered one HubSpot company, one contact, four expected onboarding tasks, one welcome email, one internal handoff email, and one kickoff Calendar event. Those artifacts were manually cleaned up and the smoke run was closed; the Make execution was retained as run evidence.
What this does not establish
This experiment deliberately used exactly one send. Its read-only preflight did not establish duplicate or replay safety, so it makes no idempotency claim. The separate duplicate-records experiment is the relevant evidence for that different question.
It also does not show that every Make scenario clones cleanly, that a cross-team clone behaves the same way, that all connection types are portable, or that webhook configuration is automatically preserved. One successful run does not establish reliability.
The accurate conclusion is narrower: for this tested same-team scenario, the existing account/connections could be reused, a fresh webhook could be attached to the cloned candidate, and the clone, with zero semantic workflow mutations, completed one synthetic onboarding end to end without manual Make module reconfiguration.
Evidence used
This article is based on the frozen public-safe EXP-002 result:
benchmark/exp002/evidence/clone-portability-result.json. It records
categorical outcomes only and deliberately excludes provider-object IDs,
connection/account IDs, mailbox destinations, webhook URLs, and credentials.