"Evidence record: a CRM's own free form as the whole intake (native form, no automation layer)"
run recordpack hubspot-native-intake-v1tested 2026-08-22
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
If you are already on a free CRM plan, does its own form do the client-intake job on its own, and what does it not do?
What was tested, and when
| Pack | hubspot-native-intake-v1 |
| First tested | 2026-08-22 |
| Runs | two independent runs on separate days (2026-08-22 and 2026-08-23), each covering the same six cases, plus a user-agent diagnostic and an ordinary-browser control |
| Status | passed |
| Pages built on it | tested-hubspot-native-intake, hubspot-native-vs-stack, who-should-not-use-this-stack |
Stack and plans
- Form: the CRM's own form builder, free plan, published as a standalone page
- Automation: none, which is the point of this pack
- CRM: HubSpot Free CRM, EU data centre
- Email to the lead: none configured, see limitations
How we tested
A six-field intake form was built in the CRM's form builder and published. Scripted browser submissions were sent from a controlled machine, twice on separate days, using an ordinary desktop browser user agent unless a case says otherwise. Every case was verified by reading the records back through the CRM's API (creation time, source, form fields, conversion counters) and by reading the notification mailbox. No records were created or edited by hand during the runs.
Cases
| Case | Input | What we observed | Ops | Status |
|---|---|---|---|---|
| new lead, plain characters | a previously unseen address with all six fields filled | contact created about one second after submission (1.03 s and 1.18 s measured), carrying the form as its source and first conversion, lifecycle stage lead, and all six field values including both dropdowns; one notification email | n/a | confirmed (both runs) |
| repeat submission of the same address | same address 123 seconds later in run 1, 73 seconds later in run 2, with changed company, service interest and budget | the same contact was updated, no second record was created, and the contact's form-submission counter moved from one to two; the notification arrived as a reconversion rather than a new submission | n/a | confirmed (both runs) |
| special characters | Nordic characters and an apostrophe in the name and company | values stored intact in the name, company and message fields | n/a | confirmed (both runs) |
| malformed address | an address with no top-level domain | the form stayed on screen with a field-level error and nothing was created | n/a | confirmed (both runs) |
| required field missing | the required name field left empty | a field-level and a form-level error, nothing created | n/a | confirmed (both runs) |
| two submissions of the same new address a fraction of a second apart | parallel submissions, 106 milliseconds apart in run 1 and 235 milliseconds in run 2 | exactly one contact in both runs, and two notification emails in both runs (one new submission, one reconversion), while the contact's own submission counter read one rather than two; the run 1 counter still read one about twenty hours later, so this is not indexing delay. In both runs the later-arriving submission supplied the stored field values | n/a | confirmed (both runs); the counter behaviour is the finding, and the later arrival won both times |
| deals | every case above | no deal was created by any submission in either run; the only deal on the test days came from an unrelated automated test | n/a | confirmed (both runs) |
| automation user-agent diagnostic | submissions from a browser whose user agent identified itself as headless, compared with an ordinary desktop browser user agent, and with the automation flag varied independently | the headless-identifying user agent received the normal success page and created nothing, in both runs; an ordinary browser in a visible window created the contact normally even with the automation flag left visible. The user-agent string decided the outcome; the automation flag did not | n/a | confirmed (drop observed twice, ordinary-browser control observed 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
- The free form creates and updates contacts by email address without any automation layer, and keeps all form fields.
- It creates no deal. The vendor documents record creation as a workflow action for paid users.
- It notifies the operator on every accepted submission, as a new submission or a reconversion. Submissions it drops silently produce no notification.
- It blocks a malformed address and an empty required field before anything is created.
- Two near-simultaneous submissions produce one contact and two notifications, but the contact's submission counter shows one. Counting intake from the record alone can undercount.
- Submissions from a browser identifying itself as headless were accepted on screen and dropped silently. This is a note for anyone monitoring their own form with a script, not evidence about ordinary visitors.
- No automation operations are consumed, because there is no automation layer. We did not test whether the CRM itself imposes a form-submission volume limit.
What it does not establish
- The lead receives no acknowledgement in this pack because we did not configure one. The free plan does offer one send-email workflow per form, but it is a marketing email restricted to marketing contacts and saving it requires an email footer with a physical postal address, which this lab does not publish. That is our constraint, not a product limit, and every page that mentions it says so.
- We did not test whether an ordinary visitor's browser can be filtered, and we did not read the vendor's own submissions or spam views to see whether the dropped submissions were recorded there.
- The ordinary-browser control was observed once.
- The later-arriving submission won both times, but server-side processing order was not measured, so treat it as an observation rather than a rule.
- The synthetic test contacts had not been deleted when this record was generated; the connector we use has no delete action, so removal is a manual step and will be recorded in the run log.
Artifacts
| File | What it is | SHA-256 |
|---|---|---|
| PLAN.md | Test plan written before the runs (not published; available on request) | not published |
| test-log-run1.md | Run log, first run (not published; available on request) | not published |
| test-log-run2.md | Run log, second run (not published; available on request) | not published |
| hubspot-form-automations-2026-08-21.md | Dated capture of the vendor's form-automation documentation (not published; available on request) | not published |
Changelog
- 2026-08-21: pack planned, hypotheses and disqualifying results written before any test.
- 2026-08-22: first run, plus a diagnostic that isolated the user-agent behaviour.
- 2026-08-23: second run on a separate day, with an ordinary-browser control; pack marked passed.
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.