Sync property values between Contact, Company and Deal Records
Would love the ability from within at least the Sales side of things to automatically map/populate Deal Properties from a Contact's properties. We came over from Salesforce where this could be done in conversion, and this is definitely an area we miss having & would make life MUCH smoother for our staff upon creating deals.
@ClemOaky you're correct - we're in the process of backfilling those values for the deal and company object. When that happens, that should get us much closer to being able to solve the issue the author raised.
We are beginning to plan how to best solve the problem of syncing property values between object records in HubSpot to meet the needs of our customers.
We would love to hear your thoughts or feedback on how we can improve your experience.
We have this need in regard to the Company / Contact relationship. There is a lot of metadata that is common to every member of a company (e.g. Industry, we have a custom 'Type' that dictates if the company is a customer, vendor, competitor, personal, other, etc.).
The problem is that if I want to create a custom view for someone to say call all of the contacts in the 'Automotive' Industry, there is no way of seeing the 'Industry' data field in a 'Contacts' list. It doesn't make sense to have to fill in or even replicate the 'Industry' Company field to the Contact field when we all know it is just a simple SQL join between those tables.
The Hubspot automations all seem to be of the data replication paradigm, which just doesn't make sense to me in most instances, when it should be a link.
Hopefully, I'm just missing some super obvious feature. Would love some help.
I would add that this should also include the newly released feature of custom objects. It would be critical to be able to share already created properties for different objects to avoid the duping of already input information simply because the property is associated to a different object.
For anyone who is interested in using workflows to accomplish bi-directional property synchronization between companies and contacts, this is what I did and it seems to work. I created a test field named banana on both record types, with the same value options of "yellow" & "green".
I built two separate workflows, one that is triggered by company-based enrollment trigger which copies properties to associated contacts, and another that is triggered by contact-based enrollment, which copies properties to associated companies.
I tested updating the property in the company record, and it will sync to any associated contacts. What's also cool is if you update the property on *one* of the contact records, it updates the company, which then also updates the other contact. So they are all in sync. Be sure this is what you want!
The key thing here is when you "review and publish" the workflow, in the re-enrollment section you need to be sure that you allow contacts to re-enroll when that property is known (again). Meaning if banana already equals "yellow", that when you change it to "green" it re-enrolls and thus runs the workflow again.
Again, I caution everyone to evaluate their use case.
If you will ever have a contact assigned to more than one company, then the property values live at the company level.
If you will ever have properties assigned at an enterprise level, with child companies that could have different values, I'm interested to hear your setup.
@KTotten , thank you for sharing this - really interesting! I am a bit surprised that the re-enrollment works this way because the property was not unknown and became known again but rather known all the time. I would have expected it needs some "updated in last" trigger.
Do you know why it works this way? 😄
Anyway, thank you for sharing this, I will certainly give it a try!
@adamkushner this is a good point; though you can add a level of security by changing the syncronization to only apply when the association between company & contact is "primary" instead of "all".
@MW96 I found this community post about re-enrollment and it seems that leveraging that "is known" trigger seems to work any time the value is changed. 🙂
