Overview
We have a team here at Etumos that focuses on how our company can assist HubSpot clients in maximizing their use of the platform. This usually involves meeting to gain a deeper understanding of new feature releases or discovering more efficient methods for common processes. However, our most recent team sync involved sharing a significant discovery related to the Salesforce (SFDC) <> HubSpot sync that, we believe, isn’t clearly documented. And we wanted to share this finding, along with other best practices, with you.
Initial Sync Best Practices & Findings
To clarify, this scenario pertains to the initial connection between your SFDC instance with your HubSpot instance, whether it’s a brand new or pre-existing instance of HubSpot. In our case, which prompted us to share this information, our client was migrating from one marketing automation platform to HubSpot while retaining their same SFDC environment. Here is what we consider to be best practice/what we learned in this process:
Migrate mission-critical fields at first.
When migrating platforms, you’ll likely be left with fields that are no longer relevant for your business. This is a great opportunity to go through a cleanup process, and you’ll want to do it before connecting SFDC and HubSpot to save yourself a significant amount of time. Once you’ve identified what you need to keep, narrow it down even more to which fields are most important today, and start with those on the initial sync. Bonus points for documenting decisions on mappings, including API names and sync rules.
Create a new profile and integration user in SFDC versus using an existing profile or user.
It is widely considered best practice to ensure each of your integrations are attached to different users. This allows teams to better understand integration performance and identify bad eggs much quicker than if you had multiple services using the same user. In addition to that point, creating a new profile for your HubSpot integration allows you to control which fields are syncing down to HubSpot upon initial sync. Remember, you can always add more fields to the profile/user access after the initial sync. This makes all your work in the first step worthwhile and leads into our third, and arguably most important, finding.
Initial sync and post-initial sync property mapping behavior differs
The SFDC <> HubSpot integration acts differently regarding property creation before and after the initial sync, which was our most important learning. We will talk more about this below.
Expanding upon Hubspot Documentation
We love helping our clients get the most out of their investment in HubSpot, and their documentation is top-notch. While the documentation is accurate, we felt as a team that there’s a missing component on this topic, specifically as it pertains to that initial sync and when properties get created. And that’s the reason we wanted to write this blog.
The current HubSpot Knowledge Base article mentions, “HubSpot will create mappings between HubSpot properties and SFDC fields regardless of which setup you choose. If the SFDC field does not have a matching HubSpot property, a new property will be created in HubSpot by Unknown user.” Essentially, if the HubSpot Integration user has access to more fields in SFDC than needed, companies run the risk of creating a large number of unwanted HubSpot custom properties. This speaks to our first and second recommendations above in that it is essential to create a data dictionary of the must-have fields and expose only those to the new integration user. If you need more fields in the future you can always create additional mappings after the initial sync.
This is not to be confused with the scenario described in this HubSpot Knowledge Base article that discusses syncing down SFDC fields after the initial sync between the two systems. In this scenario, users can create the property in HubSpot first and then manually match the property to the SFDC field. The property isn’t automatically created in HubSpot when you give the integration user access to the field in HubSpot, so there’s no risk of creating a duplicate property.
Unfortunately, the article doesn’t go into further detail on how HubSpot identifies matching properties between the two systems, thus opening yourself up to the possibility of creating duplicate or unintended properties in HubSpot.
Why This Matters
Let’s be straight about it: It isn’t the end of the world if you accidentally create duplicate properties within HubSpot. It’s more of an annoyance than anything, but that annoyance can cause a delay in your implementation or migration if you need to account for time to delete those duplicate properties. It can also cause your sync time between SFDC & HubSpot to rapidly increase and/or go over the allotted API limit if you don’t have a healthy integration established. The best course of action is to follow these best practices so you don’t find yourself in a sticky situation.
Conclusion
Looping back on the project with our client, we followed these best practices and were able to successfully guide them through their migration. As you can see, though, there are multiple junctures where the project could’ve been delayed, and we wanted to share our knowledge before you begin this process yourself. Whether you’re migrating to HubSpot for the very first time or are restarting with an existing HubSpot instance, learn from our experience to build a healthy and scalable integration between SFDC and HubSpot.
