HubSpot auto creates a contact for anyone that emails in - or is cc'd into a reply in conversations. For some customers who manage through support, this will mean a large number of contacts can enter the database. The only way to prevent this at the moment is by setting filtering rules, as all filtered emails do not create contacts. There is a use case from a customer in this post [Hyperlink removed by moderator as it linked to an archived Community post with duplicate information]
This is a request to build a "Create contact" rule giving us the option to disable automtically creating contacts for people we communicate with in Conversations.
I would agree with a previous poster that this is absolutely not ONLY related to "Conversations". This should be a major, global setting. For email responses, IF a Contact does not already exist, "Do not create the Contact". I realize that Hubspot is a Contact tool, and you need to create Contacts based on different criteria, but why not implement the ability to NOT create contacts unless explicitly selected in a module? Like in Forms, if a contact fills out a form, I completely would expect a Contact to be created, as you need to store their response with the Contact name. But for a tool like email integration, you need a different model entirely. Basically it should default to not creating Contacts unless someone specifically configured it to do so (but even then most would disable it for the same reason as you have hundreds or thousands of people asking for this to change). NOBODY wants tons of unwanted, unhelpful email addresses clogging up their CRM and creating busy work. If you think people are being frustrated or rude in their comments they have a very good reason to be. It is shameful that this problem has been mentioned for 7 years. This is ridiculous for a top-end Contact product to have ZERO way to be configured to keep random email responses from creating Contacts, which kicks off processes and wastes time.
Please, please, please (pretty please with a cherry on top!)—just give us the option to turn this feature on or off. I'm sure there are users who find it helpful, but judging by the feedback, we’re one of many—perhaps close to 1,000 users—who would love to see this feature removed or at least made optional.
It’s a huge pain to go through and delete dozens of irrelevant contacts. Out of 20 suggestions, we might want to keep one. It would make a world of difference if we could simply manually add the contacts we actually need. That can’t be too hard to implement, right?
Thanks for considering! It would save us a lot of time and frustration.
It would make a world of difference if we could simply manually add the contacts we actually need. That can’t be too hard to implement, right?
Arrested Development Narrator: It would be too hard.
I'm still here folx, promise. In a previous post I allude to why the front-end of this feature seems dead simple, but the backend (our email system entirely supposes every message is associated with a Contact) would need an 'unknown visitor' treatment a la Live Chat.
Very very sympathetic to the current pain, wasted time folx are experiencing. Thematically, we are examining ways to make settings/features/configuration more consistent across all channels, email included.
Our team is finding it so frustrating that HubSpot creates a contact for everyone in CC. We've got a contacts list full of people we've never directly received an email from.
There are times when we might want to log an email sent via Outlook, but not some of the CC'ed recipients. It would be useful to exclude certain contacts in the email chain from having a contact entity created in this scenario.
This idea's status has changed from ‘Being Reviewed’ to ‘Idea Submitted’. This change is due to our improvement project to update our Ideas Forum statuses in order to provide better transparency into how we are listening to your feedback.
“Idea Submitted” means that our product teams are aware of this feedback and are monitoring the need for this feature alongside other inputs that determine their priorities & roadmap.
For more details about the statuses we use on the Ideas Forum & what they mean, you can read this community post here.
This needs to be addresses. I have just had an instance where I've emailed sesnitive information - not to my customer, but rather to the original email address of an email my customer had forwarded to me - as Hubspot had pulled this third-party email address, created a contact for it and set their email address as the default to reply to (as it had assigned the ticket to the new contact).
Hi, Eric. From my perspective, we simply don't need to keep track of every single person that is ever copied on an email. We just need records for the people we communicate with directly. We're using Hubspot's Data Quality tool. Unfortunately, by automatically adding everyone whose ever CC'd as individual records, you're also creating hundreds if not thousands of records with formatting issues. In almost all cases, the new records that are created only have an email address, so there's no first name, last name, company name, etc. If I want to scan through formatting issues to fix them, I've got to wade through a bunch of useless contacts to do it. And there's no way to stop these useless records from being created. James
The problem occurs particularly when an individual is cc'd on a conversation or email. That cc triggers a contact creation, which essentially becomes a blank instance/contact. That individual never has a deal attached, never becomes a marketing contact, etc. It just sits there and creates clutter. With many conversations going in and out during a day, plus engineers needing to include everyone on correspondence, we have quite a messy contact list.
Not sure if it's possible in your particular situation, but if you contact HubSpot support, there may be a way to automatically delete any contacts that are created as a result of being cc'd. Good luck!
This feature prevents using Hubspot as a support / ticketing system as our email volume grows and manual deleting becomes too much work. It's better used in sales and marketing. Pity if everything can't be in one place.
The issue we've been running into particularly here is when internal staff email these connected inboxes (such as ticket channels etc), it generates a contact record for them. Then, their internal meetings and confidential internal emails suddenly become open to everyone in the company, causing obvious issues. @EricHirsh@hhiggins appreciate your thoughts on this one, if there's a better way to prevent this?
This wouldnt be so bad except that the contact creation and merging process (when a contact already exists from that email) now updates the Record ID to a new value for the original contact instance. Any integrations or API's that relied on what should be an immutable record property now breaks. If you want to fix this, then allow record merges to preserve the original Contact Record and its Record ID property. The way Hubspot handled this defies all Database design logic since the invention of databases and data integrity.
This also affects the Record Merge feature, where it still shows as preserving the Record ID property of the chosen record, but in fact sets a new value on the merged record. Any external systems that relied on what was supposed to be an immutable property can no longer have any immutable property in a hubspot contact record.
Example use case: If I have a Hubspot workflow that calls a 3rd party api to push rcontact ecord data updates (maybe a new Meeting created etc), if we relied on Record ID, we cant push a payload of a known record ID because its now different. We cant do 3rd party record syncing effectively because of API rate limits at the secondly level. They dont support enterprise level API rates.
Has any other user been able to fix this? Our team is using the inbox and lots of contacts are being created unnecessarily and it's really a hassle to go over those and deleting them manually.
Debe ser un usuario registrado para añadir un comentario aquí. Si ya está registrado, inicie sesión. Si todavía no está registrado, hágalo e inicie sesión.
