Considerations for Managing the Salesforce Extension Within HubSpot

Where to start? Let me be honest, writing an introduction to something as technical as the Salesforce Extension for HubSpot isn’t the easiest thing to do. I guess the best thing I could say to you at this point is “Congratulations.” You’ve made your way through the successful curation of two of the largest CRM products in the world, and now, you want them to play nicely together (what was that old saying about keeping your enemies closer?). 

It’s no secret that HubSpot and Salesforce have both earned their spot at the CRM table in the Oscars of B2B history, but each of them has certain superpowers that continue to differentiate them from their opponent. HubSpot, originally solely a marketing platform, has spent years perfecting the equation for attractive yet easily-created content and collateral. Salesforce, the original CRM (as some have called it), continues to build focus on sales processes, forecasting, and developer visibility. A tech stack could require harnessing both superpowers in a seamless exchange of information. That’s where you come in!

This isn’t another “How To” guide on connecting HubSpot and Salesforce. There are a million different resources on that topic available for you. The connection of the systems is the fun part! Excitement is high, and the willingness to complete the implementation is unrivaled. You’ll be fine (trust me!). This article is for the Sys-Admins and RevOps peeps who are two years into a HubSpot/Salesforce blended tech stack, the ones who have a single-cup Keurig plugged in at their desk, the ones who know what it’s like to check the same sync errors screen every weekday until they can draw it from memory. You know who you are - I’ve been there too. 

My job for this post is to share my top considerations for long-term success using the Salesforce Extension in Hubspot and to ensure you have the tips and tricks to keep things running smoothly!

You Don't Need Everything, Everywhere, All the Time

If you had asked me the definition of a successful system integration early in my career, I would have told you something like, “Every piece of data is visible, editable, and fully up-to-date in every system.” How many of you readers just shivered a bit? Nowadays, my answer is a bit more admin-y. "Well, I guess that depends on what you want to do with it.” 

Data sharing between systems does not need to be, and many times shouldn’t be fully exhaustive. If you have a complete copy of your entire database in two separate systems and can do anything you need to in either system, why are you paying for two separate systems? Now, this is where some of you will have a lightbulb moment. If that’s you, let’s talk. If you’re sitting there yelling “DUH!” at your computer screen, we can continue. 

The properties you sync, how you sync them, and how they’re updated must be defined and reviewed. In most examples of a Salesforce <> HubSpot blend, you want your marketing to function mainly out of HubSpot, but your Sales team will continue to work out of Salesforce. This is a typical setup that bodes well for both of these systems and plays to their superpowers. Once you’ve fully delineated the functionality you would expect from both sides of the world, take some time to understand precisely what data is important to each function. Here are the questions I ask myself each time I evaluate a Salesforce Sync with HubSpot:

👉 Which teams do I expect to work inside HubSpot? In Salesforce?
👉 What information do they need to do their jobs? 
👉 Where does that information live? Where SHOULD it live?

Let’s use an example.

You currently have a HubSpot instance integrated with Salesforce. You’re following the same basic pattern that many businesses have before. Your marketing team handles all inbound within HubSpot, farming them out to your Sales team, who will pick them up in Salesforce and use dark magic and custom discounts to close the deal (or whatever Sales actually does with them). Today, in your current setup, you have many of the Salesforce Opportunity fields mapping into HubSpot Deal properties. Why? Does it impact your marketing? Do you segment customers based on any information from the deal? Or can you find it all on the Company record?

Understanding that the most extensive integration isn’t always the best integration is something that many SysAdmins or RevOps folks don’t learn enough about until it's too late. I urge you to think it over, map it out, and start turning off unused properties in your mapping. You’ll be surprised with just how few hiccups you’ll see as a result. Bonus point, you can always re-map and trigger data syncs later if necessary!

A Picklist is Just a Picklist...Until it's Not

If you’ve managed a Salesforce Extension with HubSpot, you know the Sync Health page well. If not, here’s an excellent knowledge base article by HubSpot. Regular review of this page is essential for all instances connected with Salesforce. Any sync error on this page can halt all syncs for impacted records, so it’s crucial to review and address them regularly. Inbound MQLs stop syncing with Salesforce with as little as a misspelled picklist value! The panels on this screen indicate the following:

• Associations: Records failing association syncs can lead to abandoned companies, contacts, & deals
• Picklists: Misaligned Property values in dropdowns between HubSpot and Salesforce
• Custom Code: Automation within Salesforce is failing, usually caused by an unexpected property value
• Field mappings: Record sync fails due to a property type discrepancy or a removed Salesforce field
• Duplicates: Records creation cannot occur because a duplicate record or value already exists
• Property Values: Records are failing the sync due to invalid property values
• Permissions: Records fail the sync due to the connected user’s access to the Salesforce field or object**
• Other: Records aren’t syncing due to an unknown error (HubSpot Support can help).

⭐ Pro Tip: Spend a Salesforce License on an “API User” or “Integration User” seat with full, Sys-Admin permissions. This will prevent any system permissions issues. This “user” needs full read, write, and delete access.

These seem somewhat simple. Let’s say you come in and check the Sync Health page in HubSpot one day, and BOOM… there it is… a brand new, fresh picklist sync error. Itching for a quick win early in the morning, you do what any sane person with full admin rights would do; you open it up and take a look. You cross reference the two systems and find the exact same picklist value in both systems. Both are spelled the same, spaced the same, and identical (you’ve even checked the end of the values for that dreaded ghost space). What’s happening?

Picklist-type errors can show up when picklist values are misaligned or misspelled, BUT they can also show up when the values are correct, but one record violates a Salesforce Validation Rule. For those unfamiliar with Salesforce Validation Rules, it’s an easy way to restrict the selectable values in a dropdown based on another dropdown or field value. For example, let’s say that you are selling cars and entering your customer’s preferences of make and model into your CRM. You can use a validation rule to limit the possibility of combinations like “Toyota F-150” and “Hyundai Corvette.” 

Even though F-150 and Corvette are fully valid dropdown options for Model, the Make you’re selecting has to be appropriate. Returning to your Sync error, you find that the impacted Picklist is “Model.” You see a value of F-150 staring you in the face (again, a perfectly valid answer), but there is ZERO explanation as to why that value is failing. That is until you find the Salesforce Validation Rule requiring that Make be set to “Ford.” Updating the value for Make on these records will fix the issue, proving that a picklist is just a picklist… until it’s not. 

API Calls? Can I Just Text Instead?

Like the vast majority of the public, for me, APIs remain an extremely important galaxy of dark corners, questionable values, and duct tape. However, there are two key areas of the Salesforce Extension for HubSpot where API Calls must stay top-of-mind. 

First up is your allotted Salesforce API call limit for HubSpot use. You’ll see this as a big progress bar across the top of your sync health screen, refreshing every 24 hours. On average, API limits usually aren’t of any concern in the day-to-day use of this integration. However, on days when you have imports running, property mappings re-syncing, or any other kind of background task, API calls need to be monitored and regularly reviewed. At any point, you can update the amount of Salesforce API calls allowed to be used by HubSpot up to the maximum amount permitted by Salesforce. 

Two general reminders about your API Call usage:

1. API Calls are not a 1:1 relationship with Contacts, Companies, or Deals. Often, a single contact syncing to Salesforce takes up a handful of API calls. Contacts with more associations, properties, and data can take more calls (and therefore more time) to fully sync. 
2. If you were to hit your allotment of API calls for the current 24-hour period, don’t dismay. Records will stop syncing but will resume as soon as more API calls become available—no need to do database cross-references and manually re-sync records. The integration will simply pick up where it paused.

Ensuring Your Sales Team Has Unbridled Access to HubSpot

If this statement made you spit up your coffee just a bit, good! I’m glad. Remember the specific roles and jobs to be done that we outlined in our first step? Let’s pick that back up. As a refresher, the questions that you’ll want to ask yourself when reviewing your Salesforce and HubSpot sync are:

✅ Which teams do I expect to work inside HubSpot? In Salesforce?
✅ What information do they need to do their jobs? 
✅ Where does that information live? Where SHOULD it live?

We all know how frustrating it is to be on the bad end of a permissions issue, but setting up the proper visibility and access in each system is an important safeguard to keeping your data in a good place. Chances are, you already have somewhat of an idea of how these should be built around your organization, so I won’t spend valuable time telling you how to develop a roles and permissions plan. I will walk you through a couple of examples of how that plan overlaps with the settings of the Salesforce extension. 

Property visibility is one of the more common permissions issues seen when using the Salesforce Extension for HubSpot. If the integration user cannot see a particular mapped field due to Salesforce role-based visibility, the sync will not function as expected, resulting in a sync error. The best way to ensure a seamless transfer of properties to and from HubSpot is to make all system properties visible to your integration user in both systems. 

The same logic extends to system users! Mapping properties into the extension between Salesforce and HubSpot will not override field visibility rules set in Salesforce. Playing around with both systems' current roles and visibility rules may take trial and error, but a necessary evil for those using the extension.

Nobody can outline all the nuances and considerations at play in the successful setup and management of the Salesforce Extension for HubSpot. Still, I hope you’ve gained some insight as you’ve read. As the lucky person tasked with managing this integration, I genuinely wish you the best!