Copy or duplicate properties between objects - good or bad?

Smart CRM & Sales Hub Tips, Tricks & Best Practices
1

Using workflows, you can copy key information between companies, contacts, deals, tickets, and so on. But is this even a good idea? First of all, there seems to be a reasonably high risk of information not copying, for example:
- Someone changes the ticket property ABC, but you only have a workflow copying the contact property ABC to the ticket, not the other way round.

- You have a workflow saying that if the company property EDF updates, copy it to all contacts, but when a new contact is created and associated with the company, your workflow is not triggered as there hasn’t been an update to the property.

Not saying any of the above can’t be addressed but it’s complicated and it’s easy to suddenly realise your information is out of sync.
With that in mind, is it perhaps better to just have a “master property” on one object? The only drawback I see is that when you create a “view” on on an object, you can only filter by same-object properties.
Keen to hear how others have solved this.

2

Hi @enorberg,

Generally I would follow a principle of “don’t copy anything between objects unless it’s really, really, really necessary”. Copying information between objects has obvious downsides, such as the risk of such a sync being setup incorrectly (not taking into account all potential scenarios), user input being slightly faster than HubSpot workflows and workflow outages, which happen every once in a while.

I often see values copied from one object’s records to another purely because users do not want to navigate to the associated record. It’s understandable that users would like to have all information at a glance but sometimes, key information can simply be displayed on the cards of associated records in the right sidebar.

This also has an aspect of training and having everyone understand which object certain information belongs to. While it might be easier and at a first glance intuitive to update everything on the contact record, users need to understand the difference between user input on the contact, company, ticket, deal record and how information between these objects can be referenced in list filters, cross-object reports etc.

I would always critically challenge a request for copying information from one object to another. Sometimes, there’s a better way. (Sometimes, there isn’t.)

When values are needed for workflows, filtered views or reports, it’s important to define whether it’s a one-way or two-way sync. In the former case, everyone needs to be aware of the fact that updates on the receiving end won’t update the original record. If it’s the latter, it needs to be implemented in a way that doesn’t cause a loop – a bit of a brain-teaser but possible.

The specific case of a sync not re-triggering when a new associated record is added (e.g. workflows copies values from company to contact, new contact is added after first ‘sync’) can be address via re-enrollment triggers based on the Number of associated contacts.

Having said all that, the product team is currently reviewing a request to keep properties in sync which would solve much of the points mentioned above. I’d recommend upvoting and commenting to follow updates on this request: Sync property values between Contact, Company and Deal Records

Best regards!

3

Thanks Karsten, that’s a very thorough answer and somewhat in line with what I had in mind. Does anyone else have any input? I can see that the proposed sync (it’s been In Review for years, so who knows when it will happen) would mitigate most of my cornerns, however, it seems to me that instead of syncing properties, they should be useable across objects, removing the need for copied properties altogether.
I’m currently exploring making the synced properties “view only” which helps the one-directonal sync, although I can see it being confusing to the user (e.g. having to go to a contact’s associated company to change Industry, for example).

4

Copying properties between objects is a BAD practice and should be done when absolutely necessary.

I understand the use cases eg. to filter contacts by a company property. But do note, copying properties from workflows across objects (Company > Contact) will always cause update anomalies in some records not enrolling or re-enrolling in workflows.

Also we need to think through if it needs to be a 2-way sync too? (Contact > Company) which can cause loops.

The best way is to have the cross-object properties accessible ‘by reference’ instead of ‘copying by value’. Looks like Hubspot is playing catchup to Salesforce here. SF has ‘lookup fields’, hubspot is working on something similar since forever.

Till then we can continue using custom properties and workflows to copy values, but I’ll always cringe when I see this implementation:) This is a classic case of what is called ‘database de-normalization’ which can keep data and backend devs up at night.

Fortunately, or unfortunately in Hubspot admins are free to copy as many properties across objects without facing consequences of bad database design.