Advertising notice: this page contains no advertising (affiliate) links; every product link here is a plain link. We do have one affiliate partnership, with Make since 2026-08-22, and its marked links appear on two other pages. The failure modes below were tested and published before that partnership existed and have not been edited since. See advertising disclosure and privacy.
What breaks in a no-code client-intake automation: 7 failure modes we observed, and the fixes we tested
Tested 2026-08-16 on the free tiers of Tally, Make, HubSpot and Brevo. Our client-intake workflow completed both of its formal lab runs. This page is about the ways it stopped working during those runs, on purpose and by accident. Every mode below was observed first-hand. For each we say how we saw it, what it meant in our test, and whether the fix is tested (three are, as of 2026-08-20) or not.
Who this page is for: anyone about to connect a no-code intake workflow to real leads and wondering how it fails. Who can skip it: if you capture leads with HubSpot's own free form builder and no automation layer (checked 2026-08-18), most of these modes do not apply to you; that is also the simplest non-affiliate alternative to this whole stack.
1. A failed step can look complete inside HubSpot
What happened. We broke one step on purpose (the call that links a deal to its contact) and submitted a lead. The contact was created. The deal was created. Then the run stopped: the deal stayed unlinked and the acknowledgement email was never sent. Same result both times we ran it, with identical HubSpot 400 responses.
What it meant. Make reported the error in its run history (and see mode 2), but the contact and deal lists in HubSpot looked normal. The two missing pieces, the deal link and the reply, are not visible at a glance in the CRM.
Tested fix (2026-08-20). We attached an error-handler route to the association step: an alert email to the operator, then Make's Resume directive so the run continues. Re-ran the same broken call: the run ended as Success, the lead still received the acknowledgement, we received the alert naming the lead and the failed step, and the scenario stayed active. The deal is still left unlinked; the alert is what tells you to fix it. On 2026-08-21 we extended the alert so it also carries HubSpot's error message, the execution id, a link to the run in Make's history, every form field and the contact and deal ids, and provoked the same failure again: same outcome. The email now carries the deal and contact ids you need for the manual fix; we did not navigate the run-log link from a signed-in browser. Observed once with the extended text. (Make documents five handler directives: Skip, Retry, Resume, Commit, Rollback; Rollback is the default when no handler is attached, checked 2026-08-20.) Observed once so far.
2. One error switched our webhook scenario off
What happened. After each forced failure, the run history showed: "Scenario was deactivated by Make because: scenario has encountered an error." The scenario was off.
What it meant. This is documented behaviour (checked 2026-08-20): webhook-triggered scenarios are disabled immediately on an error; scheduled scenarios are disabled after three consecutive errors. In our test one invalid API call was enough. We did not test other error causes.
Tested fix (2026-08-20). With handler routes attached (mode 1 and mode 4), two deliberately provoked errors ended as handled runs: the scenario's error counter did not move and no deactivation event appeared. A manual check of the on/off state remains sensible; we have not tested what frequency that would need in real use.
3. When we switched it back on, the backlog ran at once
What happened. Three round-two lead cases, plus one healthy failure-case submission, were queued while the scenario was off. On reactivation, four executions ran within about one second of each other.
What it meant. In this test the queued submissions were not lost. That burst is what exposed mode 4.
Mitigation status. Untested. In our test, reading the run history after reactivation is how we found the failed execution.
4. Duplicate protection has a race window
What happened. Our dedupe logic searches HubSpot for the email first and only creates a contact when nothing is found. In the 25-second-spaced formal run, the later duplicate was handled correctly (short update path, no second contact, deal, or email). During the reactivation burst, a duplicate arrived during the roughly one-second queue drain. The search returned nothing, the create ran, and HubSpot's email-uniqueness rule rejected it with a 400 error, which triggered mode 2.
What it meant. Search-then-create is not atomic. We observed this during a queue burst; double-clicks and retries are plausible additional causes that we did not test.
Tested fix (2026-08-20). We switched the search from a free-text query to an exact email filter, then attached a handler (alert email + Ignore directive) to the contact-creation step and submitted the same new address twice, 29 milliseconds apart. The race still happened (it is HubSpot index lag, not the filter), but the outcome changed: one contact, one deal, one acknowledgement, one alert to us, run ended as Success, scenario stayed active. Trade-off: the duplicate submission's data is dropped rather than merged into the existing contact. Observed once. An email-keyed create-or-update path remains unverified. For scale: on 2026-08-21 a duplicate that arrived 2.1 seconds after the original was found by the search and took the normal update path. The only slip we have observed is the 29 ms case (one observation each).
5. The audit trail on the free plan lasts 7 days
What happened. We read the account limits through Make's API on 2026-08-20: the free plan's license lists a 7-day retention, at most 2 scenarios, and 1,000 credits per month (simple operations consumed 1 credit each in our runs). In our account, run list entries older than 7 days were still listed but marked not replayable; we could not retrieve per-module detail through the API for any run, so we cannot say exactly what the 7 days covers beyond what the license states.
What it meant. Do not count on reconstructing a two-week-old run from Make's logs.
Mitigation status. Observed practice: we captured screenshots of failed runs on the test day. Exporting run details and paid-plan retention terms are untested and unsourced here.
6. "Run once" does not save your work
What happened. We built two modules, tested them with "Run once", closed the browser, and they were gone. Run once executes the current editor state; it does not persist it.
What it meant. We rebuilt both modules from our notes in about ten minutes.
Mitigation status. Observed: saving explicitly before leaving the editor prevented a repeat for the rest of the build.
7. Two things the module list did not tell us
- The two personal-Gmail connection methods we tried were refused. Make rejected a personal @gmail.com sender on plain SMTP and on its restricted Google OAuth path. Make points to a custom Google Cloud OAuth setup as the remaining route; we did not test it. We used a transactional service (Brevo, free tier, checked 2026-08-16) instead; its emails reached the Gmail inbox, not spam, in both rounds. At that point the visible sender was rewritten to Brevo's shared domain because ours was unauthenticated; after authenticating our domain (2026-08-22) the acknowledgement arrived from our own address with DKIM, SPF and DMARC passing, observed once. Other mail providers untested.
- Our deal was created unlinked to its contact. The compact Create a Deal configuration we used exposed no association field, and the deal we checked showed "Contacts (0)". Tested fix: one raw HubSpot API call that links deal to contact; it is included in the exported scenario blueprint in our evidence pack.
Before trusting real leads
Tested by us (each observed at least once, dates shown):
- Error-handler routes with an alert email on the contact-creation and association steps (2026-08-20): handled errors no longer deactivate the scenario, the operator is told, and the lead still gets acknowledged when the association step is the one that fails.
- An alert that names the error, the run and the lead (2026-08-21): scenario name, failed step, HubSpot's error text, execution id, run-log URL (format matches Make's history view; not navigated in the test), all form fields, and for the association failure the contact and deal ids. Four handled failures that day left the error counter unchanged and the scenario active.
- Exact email filter in the CRM search instead of free-text query (2026-08-20).
- Saving the scenario explicitly after every edit (prevented a repeat of the module loss).
Not validated as mitigations by us:
- A periodic check of the scenario's on/off state (frequency unknown).
- Reading the run history after any reactivation (what we did; not tested as a routine).
- Capturing failed-run details within the 7-day retention window (limit checked 2026-08-20).
- A spare test submission to verify the chain after changes.
What we have not tested
Any upsert-based dedupe, paid-plan retention, expired connections or vendor API changes as error causes, other mail providers, sending from an authenticated custom domain, and the handler fixes beyond a single observation each. When we test them, this page changes.
Evidence packs: client-intake-v1 (tested 2026-08-16, two rounds, two forced failures) and client-intake-v2 (tested 2026-08-20, error handling; extended 2026-08-21 with richer alerts; verified through Make and Gmail APIs). Material statements map to this page's claim ledger; inferences and untested options are labeled as such.