HubSpot Ideas


Option to not assign a contact owner during first email

During testing of a unique business case, I identified that an unassigned Contact will be automatically assigned a Contact Owner if an email is sent through a connected inbox.
Example: contact John Doe does not have an assigned Contact Owner. Sally Smith has a connected email and sends John Doe an email. As a result of this email, Sally Smith automatically becomes the Contact Owner of John Doe. This is not preferred. When I test changing other properties (i.e. change the Job Title or other custom fields) this automatic assignment does not occur. Only when emails are sent through a connected inbox.

I would like an optional setting to turn this off. There are many instances in which I do not want an automatic assignment of contact owners (when the contact is unassigned).

35 Replies

+1 agree with all of the above. Lots of extra time required to review and change contacts inadvertantly assigned to allow the entire organization to view the contact.  Perhaps the amount of time the entire HS community spends fixing this could pay for the development time within 1 day of its release!





Member | Partner
Member | Partner

Sadly, it would appear this issue had been known for a number of years but no progress has been made with the developers. As a HubSpot partner we have clients with sales teams that leave a company/contact as unassigned becasue all sales personnel have the opportunity to work it. In addition we have users who need to email managers and every time I unassign the company contact as soon as one of the salesmen emails them they become the contact owner and the other sales people cannot access the record. 


Support sugested this work-a-round which willnot work in any of our use cases but it may work for someone else. Good luck!


"Would you consider at least changing the user permissions from "Owner only" to "team only". Then you could create 1x placeholder user for each team and assign those contact to the respective place holder user (owner) for that team and the remaining users within the same team still would be able to access the record."


We have experienced a similar sitauation. We get a lot of leads emailed to us from and other no-reply type addresses. These lead emails accumulate together under the relevant noreply Contact. TheContact Owner of this record is supposed to remain "unassigned". Whenever an employee accidentally does a "reply" to one of these emails via a connected inbox, HS assigns that that employee as the Contact Owner and all subsequent leads from that "noreply" email address bypass our Conversations Inbox and go straight to that person. This was very inconvenient and caused fresh leads to be overlooked because they get assigned to someone in Customer Support instead of Sales.


Here is how we partially solved our particular problem. You mileage may vary:

Create a workflow like below:




Now any Contacts with "noreply" email addresses will never have a specific Contact Owner - at least not for very long. Workflows sometimes take minutes to execute, so there is still a window for errors to happen. But at least that window is now minutes and not hours or even days.

This solution might not be optimal for you.




Top Contributor

+1 from me, lending my voice to the crowd!

Effectively in many CRM setups I work with, "Contact Owner" translates to "Sales Contact Owner". New ownership properties are created for different teams.


I'd create a workflow to clear the owner if the the team is not a sales team, but you can't use Hubspot team as a re-enrolment criteria (to do this repeatedly if needed). So this option to not assign contact owner in the first place is important




I have observed that too, and it is pretty annoying. 


Just came across this in our business, not helpful as we clear down ownership when deals are closed so they are fair game for the sales team when they come back in. 


I'm concerned about the same happening with ticket response an assignment as mentioned already as we haven't even scoped out service hub work yet. and if it means re-doing the sales hub work it could be a major problem. 


+1 Extremely annoying


I agree! this would be tremendously useful! If I go to a contact record in Hubspot and manually assign it to a team member, Hubspot should not come up right behind me and overwrite this property. It's frustrating that there is no easy resolution to this issue. I've tried creating workflows and other workarounds, but none have been able to keep our contact owners 100% accurate... either we should be able to eliminate the 'Contact Owner' property in its entirety because it doesn't work properly, or Hubspot should fix the issue so that it works more accurately (or at the very least, allow us to pick and choose which contact properties an API/or other Hubspot features can update).


When contacting Hubspot support, I was only given two options as a workaround for this issue. The first one was to set limits on who can update this property (even though it's a Hubspot error that is causing this issue) or to turn off the API feature that automatically updates contact properties (even though this is a very valuable feature that we use to keep various other properties up to date). 


Lastly, I believe it's more than just an API update that is causing the 'Contact Owner' property from being updated inacurately. In one particular instance, the history of the property update revealed that it was changed due to the use of the contact profile in a sales inbox extension. I'm not entirely sure what this means, but usually in instances where an API is the reasoning behind an update, the history will include API in the source field. 




Your assistance in fixing this issue would be greatly appreciated. Esspecially since I will now have to keep an eye on all 5K of our contacts to make sure their contact owner property is not being incorrectly adjusted.






Is there any ETA on this one?


+1 After just a few weeks of new BDR sending emails, they own hundreds of companies. It makes company ownership insignificant and unmangeable. Please fix this!!!