Evidence record: error handling and alerts for the client-intake chain (v2, v2.1, v2.2)
This page is the run record for the evidence pack named below. It lists what we tested, when, what we observed case by case, and what we did not test. It is generated from the pack file in our repository, so it cannot quietly drift from the source. Identifiers that would expose our accounts (record ids, run ids, message ids, addresses) are left out on purpose; the underlying files are available on request.
The question this pack answers
When a step in a free-tier intake automation fails, can the workflow be made to keep running, tell the operator what happened, and still acknowledge the lead?
What was tested, and when
| Pack | client-intake-v2 |
| First tested | 2026-08-20 |
| Runs | one round per case for v2 (2026-08-20), one round per handler for the enriched alert text (2026-08-21), one healthy run for the authenticated sender domain (2026-08-22) |
| Status | passed |
| Pages built on it | what-breaks-client-intake, intake-workflow-template |
Stack and plans
- Form: Tally, free plan
- Automation: Make, free plan
- CRM: HubSpot Free CRM, EU data centre
- Acknowledgement and alert email: Brevo, free plan
How we tested
The scenario was edited through the automation platform's API, then exercised with scripted browser submissions against the live form. Failures were induced on purpose in a controlled window and reverted immediately afterwards. Each run was checked in the run history for status and operation count, in the CRM for the records, and in the receiving mailbox for the alert and the acknowledgement. Header authentication results were read from the delivered message.
Cases
| Case | Input | What we observed | Ops | Status |
|---|---|---|---|---|
| healthy run with handlers attached | new lead | full chain completed, acknowledgement delivered | 6 | confirmed |
| association step failing, handler with the Resume directive (continue the run) | association call made invalid on purpose, one submission | contact and deal created, association rejected, alert email delivered to the operator, run continued and the lead still received the acknowledgement, run ended as success, scenario stayed active | 7 | confirmed (repeated on 2026-08-21 with the enriched alert text) |
| two submissions of the same new address 29 milliseconds apart | concurrent duplicate | the search missed the just-created contact, the second create was rejected, the handler sent one alert and ended that run cleanly; one contact, one deal, one acknowledgement, one alert | 4 for the handled run | confirmed (once) |
| duplicate 2.1 seconds after the original | same address, slower spacing | the search found the existing contact and the run took the update path | 3 | confirmed (once) |
| create-contact step failing, handler with the Ignore directive (drop that submission, keep the scenario running) | an invalid property added on purpose, one submission | no contact, no deal, no acknowledgement for that submission, alert email delivered naming the failed step and the platform error text, scenario stayed active | 4 | confirmed (once, with the enriched alert text) |
| acknowledgement from the authenticated sender domain | new lead after the sender domain was authenticated | acknowledgement delivered from the lab's own domain; the receiving provider reported DKIM, SPF and DMARC as passing; no rewriting to the mail provider's shared domain | 6 | confirmed (once) |
"Confirmed" means the outcome held in every round we ran that case, which for several cases is a single round. Where a case was seen once, the status column says so, and every page that cites it says "observed once". We do not treat one observation as a pattern.
What the pack establishes
- Handled errors do not increase the scenario error counter and do not switch the scenario off.
- The Resume directive keeps the lead acknowledged when a later step fails, and leaves the deal unlinked.
- The Ignore directive drops that submission cleanly; the existing record is not updated from it.
- The alert email can carry the scenario name, the failed step, the platform error text, the run identifier, a link to that run, every form field, and the created record identifiers.
- Directives themselves are not billed; the alert email costs one credit.
- An authenticated sender domain removes the shared-domain rewrite seen in v1 (observed once, 2026-08-22). Our template page still describes the earlier unauthenticated behaviour; that update is queued and not yet published.
What it does not establish
- Most cases were observed once. The association-failure case was observed twice (once in the base version and again with the enriched alert text), and the healthy path three times. Every page that cites a single observation says so.
- The create-contact failure was induced with an invalid property, not by a real duplicate race.
- The run link in the alert was read in the delivered message; it was not opened from a signed-in browser during the test.
- A literal equals sign followed by two hexadecimal digits in the alert body was mangled in transport once; the final text avoids equals signs.
- The transactional acknowledgement still carries the mail provider's open-tracking pixel and an unsubscribe header; turning that off is queued.
Artifacts
| File | What it is | SHA-256 |
|---|---|---|
| client-intake-v2.blueprint.json | Exported scenario with error handlers (sanitised) | 28c9d367e1f6911bccb86044c5e456eb6a861659c923ba37195145c1cdc05cc4 |
| client-intake-v2.1.blueprint.json | Exported scenario with enriched alert emails (sanitised, recommended) | 823c1cde840d758008aca4f7e4d2fb29e61c0bfcca7fc9412af04b040394ff30 |
| test-log.md | Run log for v2 (not published; available on request) | not published |
| test-log-v2.1.md | Run log for the alert extension and the sender-domain change (not published; available on request) | not published |
Changelog
- 2026-08-20: v2 tested (error handlers, exact-match search) and used to update two approved pages.
- 2026-08-21: v2.1 tested (alert emails carrying the platform error text, the run identifier and the lead fields); pages re-approved.
- 2026-08-22: v2.2 tested (acknowledgement and alerts sent from the lab's authenticated domain). Page wording update is queued and not yet published.
Corrections are welcome: hello@workflowtestlab.com. If you believe a result here is wrong, tell us which case and we will re-test and publish the re-test with its date.