Your website form appears to work. The visitor sees a confirmation, your team receives a notification, and the enquiry arrives in HubSpot. Later, someone spots a familiar contact with a different name, telephone number or request.
That needs a closer look than simply searching for duplicates. The immediate question is whether the enquiry reached the right person’s record. A successful submission is only useful if your team can reply with the correct context.
Imagine two visitors entering enquiries on a shared event tablet. HubSpot’s non-HubSpot forms guidance confirms that submissions sharing a cookie can reach one contact despite different email addresses. Native HubSpot forms have separate contact-creation settings.
Identify how the form reaches HubSpot
Before changing anything, ask whoever manages the website to identify the actual submission route:
- A form built in HubSpot and embedded on your website.
- An existing form built with HubSpot’s legacy editor.
- A website form collected by HubSpot’s non-HubSpot forms tool.
- A form sent through a plugin, integration or custom development.
Record the page address, form identifier and connected integration. Check mobile versions, campaign landing pages and any shared tablet used by staff. A setting on one form should not be treated as evidence that every enquiry route behaves the same way.
Also distinguish the incoming submission from what happens afterwards. If the original details are correct but change later, investigate the later update before blaming the form. Keep a short timeline of one affected enquiry so the developer and CRM administrator can examine the same evidence.
Separate normal email matching from the wrong-person problem
HubSpot’s deduplication documentation explains that a form submitted with an existing contact’s email address updates that contact. A submission using a contact’s secondary email can also replace its primary email.
That matters when several people use a shared address such as an accounts or general enquiries mailbox. A different name does not automatically make that email address a different CRM contact. Turning on a new-contact setting will not override an existing email match.
Agree what the record represents before changing the process: an individual, a shared business mailbox or another relationship. Avoid merging people simply because they work for the same company. Equally, a returning customer sending a new request should not automatically be treated as a brand-new person.
Find when the contact details changed
Open an affected contact and compare its current details with the original enquiry. Use HubSpot’s property history to inspect previous values, the date of each change and its source. You can review individual properties or the record’s wider property history.
Start with email, name and telephone number. Then check the fields used to assign an owner or personalise follow-up. Look for a change at submission time and any subsequent update.
Preserve the evidence before editing the record: the submission, relevant property changes and the contact’s record ID. Keep that material in your approved business systems, with access limited to the people handling the repair.
The aim is a clear explanation: which details arrived, which record received them, and which operation changed the values. If you cannot establish that sequence, escalate the example rather than running a bulk cleanup.
Choose the fix for your form type
Forms built with the current HubSpot editor
In the form editor, open the settings and look for Automatically create new contacts from unknown email addresses. HubSpot’s current form settings explain that enabling it prevents an existing browser cookie from attaching a submission to a previously tracked contact. An email address already in the database still updates its matching record.
When the option is off, HubSpot first tries the submitted email address; if there is no match, it can use the browser cookie. That can overwrite a contact when different people submit from the same device.
Enabling the option also turns off returning-visitor field pre-population and the form-reset link. Review those consequences before updating the form. For a shared enquiry device, separate contact identities will usually matter more than saving a visitor a little typing.
Forms built with the legacy editor
For an existing legacy form, the relevant control is Always create contact for new email address in the Options tab. HubSpot’s legacy form documentation describes the same distinction between an existing email match and cookie-based recognition.
The legacy documentation also specifies that, with this setting enabled, a different email submitted from an already cookied browser will not have views tracked for that contact, and known-value pre-population is switched off. Include that tracking consequence in your decision.
Make the change on the affected form and update it so the change goes live. Keep the previous setting in your change record. This is a targeted repair, so avoid combining it with an unrelated redesign or workflow overhaul.
Website forms collected as non-HubSpot forms
HubSpot suggests a direct Forms API connection or an existing integration as alternatives to non-HubSpot form capture. Moving to an integration still requires testing; it is not proof that contact matching is fixed.
The guidance also warns that submit clicks can collect partial submissions before external validation succeeds. Do not equate submission counts with complete enquiries.
Ask your developer to specify contact matching and field mapping. Before retiring the old capture route, verify how enquiries will reach the inbox and CRM. Check whether two active routes would send the same enquiry, and retain a monitored fallback until testing passes.
Test the customer journey, including the shared browser
Use test identities and email addresses you control. Prevent test submissions from triggering ordinary customer communications, and tell the receiving team what to expect.
Our suggested acceptance checks are:
- Two people, one browser: submit different names and previously unused email addresses without clearing the browser between them. Confirm each enquiry reaches its intended contact.
- A returning contact: submit an email already held in HubSpot. Check that the intended existing record receives the new enquiry.
- A fresh browser: repeat the first-time enquiry independently, then compare the outcome with the shared-device test.
- The complete handover: check submitted details, record association, owner notification and any follow-up. A thank-you message alone is insufficient evidence.
Test the real website page. For native forms, HubSpot recommends comparing a test submission on the standalone form page when troubleshooting: success there can point towards an issue on the page where it is embedded.
Save the test time, form identifier, resulting record IDs and a brief pass or fail explanation. Keep both shared-browser and fresh-browser checks in future testing after changes to the form or its integration.
Repair affected contacts without guessing
Fixing the submission route protects future enquiries; existing mixed records need separate attention. Temporarily hold personalised follow-up for affected records while someone verifies the recipient and request. Continue handling genuine enquiries through a checked route.
Property history helps establish earlier values, but do not assume every form overwrite has a Restore button. HubSpot limits that restore action to changes sourced from CRM UI edits, imports or workflows.
For each affected enquiry, identify which person owns the request, confirm the correct contact details and check related follow-up tasks. Correct only what the evidence supports. A bulk import of old names and addresses could undo legitimate newer changes.
Do not merge records as a shortcut for untangling different people. HubSpot states that merged records cannot be unmerged. Creating another contact afterwards is not the same as restoring the original separation of information.
Make reliable enquiry ownership the acceptance standard
A useful repair leaves your team able to answer three questions: who sent the enquiry, which contact holds it, and who needs to respond. Agree those checks with the people using the CRM, then monitor a small sample of genuine enquiries after the change.
If website enquiries are attaching to the wrong contacts, BuzzBoost can help review the website and CRM handover. Tell us which form is affected and what your team is seeing, and we can work through the route from submission to follow-up.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
