Make it possible to always create contact for new email address for Non-HubSpot forms!
When we use Non-HubSpot forms to collect data into HubSpot from existing forms on the website, the tracking code will merge contacts if they use the same computer/iPad. This is an issue for many of my clients as some have in-store forms and it also merge co-workers, and so on.
For HubSpot forms there is an option to "always create contact for new email address" - I see the need to make this an option for non-HubSpot forms as well. Or even as a global option for all forms.
I totally agree for this idea, we are facing the same issue with non hubspot form on student embedded in our student information system. Appreciate if the option of creating new contact will be applied soon to non HS forms..
This issue has just come up for us. We have most of our Users also set up as Contacts so we can send them marketing emails. ( Which touches on another Hubspot Idea: if we could set custom properties on Users, and reference them in workflows, and send them marketing emails with property tokens, that wouldn't be necessary. )
There's an RMA ( returns for service ) form on our site that's a 'collected form.' We had a sales manager who filled out this form last year just to test something using his primary Hubspot email address. Later, he submitted the same form from his computer on behalf of a customer, because that's just something sales reps sometimes do. So his primary email was changed to this client's email, and no one realized this had happened until just now when we sent out a group email to sales managers that should have gone to him but went instead to the most recent person for whom he had filled out this RMA form.
I know what needs to be done: first, apply this stupid hack to keep that specific form from being collected; then create a faceless Hubspot Form duplicating the content of that form and check 'create new contact for new email'; then use the Forms API to submit to that form. There should be a better, simpler way- but there isn't.
This feature is hugely important to us associating contacts to records using email addresses. With the contacts getting merged upon a new non-HubSpot form submission all associations fail as a secondary contact is not created. This feature would resolve a lot of issues we are seeing!
Agreed that this would be a useful feature. For users that repeatedly submit external forms using the same device (example sales rep filling up for a lead), this would resolve the issue of form submission data overriding existing contact records.
We have a similar issue and would love to see this feature added for Non-HubSpot forms. We use Non-HubSpot forms for course enrolments on our website and a lot of contacts that are being added to HubSpot via these forms are being added into other existing contacts - such as when a manager enrols two or three of their co-workers into a course at the same time, which is very common practice. So we are ending up with two or more people in one contact record and no way of recognising this unless manually sorting through contacts, which is very time consuming. Having the option to "always create contact for new email address" on Non-HubSpot forms would really help us!
Looks like this has been around for a couple of years now. Any chance we could have some input from Hubspot on the request.
I've even been trying to find out a way to be able to filter out contacts that have multiple email addresses as these are exported in a "Additional email addresses" column but it's not something that you can set a filter for or to use in a IF/THEN action within a workflow to alert us if a contact does happen to have one created. The only solution is to download the entire contact list including the multiple email address criteria selected and filter in Excel or Google Sheets... not very efficient...
This really is a necessary feature for the API to work as any developer would expect, and the issue it presents is complicated to work around. It really should be looked into, and depending on how Hubspot is architected, it may not even be a very difficult inclusion.
