Unable to identify to which object the HubSpot properties are mapped with

[Anonymous]

Hi,

I am trying to figure out to which exact objects the HubSpot properties are mapped with. Since those properties are uneditable and HubSpot support seems to be unable to provide me a clear answer, I am asking you guys for help!

 I noticed that the HubSpot property hs_email_optout is mapped to the standard field HasOptedOutOfEmail on the Contact object in Salesforce. 

But what about the other standard properties? For instance the property Email, is this property mapped to a field on the Contact or Lead object in Salesforce? 

I would be really happy if someone has an overview of the standard HubSpot properties with the associated Salesforce Field Reference. Something like this:

hs_email_optout <> Contact.HasOptedOutOfEmail

Kind regards,

Jens Wanschers

[bradmin · Accepted solution]

Hi, @Anonymous. When you look at the mappings page, the API name of the HubSpot property and Salesforce field appears: 

These API names are unique in both systems. In the case of all mappings that appear in the contact mappings page, those field names already know to write to the lead or contact. For the most part, those standard lead and contact fields in Salesforce have the same API name (like HasOptedOutOfEmail, or Email - these are the same on both objects). Others contain small variations, like the address fields. 

But if it's in the standard mappings section, there will never be a conflict writing to a field on leads, or on contacts (unless the integration user is not able to see any of those standard fields).

[Edit: The HubSpot record knows the lead or contact it's speaking to, from the sync history on the HubSpot contact. This, combined with the standardized API names between leads and contacts, ensures that HubSpot is always updating the desired lead or contact. As an extension of this and as a best practice, your custom fields mapped between leads and contacts in Salesforce should have the same API name, to preserve the same behavior.]

[Anonymous]

Hi @bradmin,

Thank you for your reply!

"For the most part, those standard lead and contact fields in Salesforce have the same API name (like HasOptedOutOfEmail, or Email - these are the same on both objects)"

How can I tell to which of the two it is mapped with? 

Kind regards,

Jens

[Anonymous]

In addition, to give you some more context. The reason why I ask is because we only want to grant the integration user access to that HasOptedOutOfEmail field on the Contact object, since it is a required field. We are not interested in syncing Contact records between Salesforce and HubSpot. We only want to sync Lead records from HubSpot to Salesforce.

[bradmin]

The way the connector works is different than you're expecting, and the use case you've laid out is not a straightforward configuration.

First, let's talk about how HubSpot knows whether it's talking to a lead or a contact. That's controlled by the Salesforce lead or contact IDs that exist on the HubSpot contact record. That value, combined with the API name of the property which is being synced, writes to the Salesforce lead or contact.

For standard fields, this is no problem, because $Lead.HasOptedOutOfEmail and $Contact.HasOptedOutOfEmail have the same API name, as does Email, as do all of the standard fields which appear in the Standard Mappings section. [This isn't technically true for address fields between leads and contacts, but this special case is already solved for by the connector.]

For custom fields, it's still doing the same thing. Most customers opt to keep their API names consistent on fields mapped between leads and contacts in Salesforce, so for them, the above behavior would still work the same: based on the lead or contact ID, HubSpot is going to talk to that Salesforce record, and if API names are the same, then there won't be any conflicts discerning between $Lead.Custom_Field__c and $Contact.Custom_Field__c. 

As for keeping the connector from talking to Salesforce contacts, that will involve extra configuration, as it's a use case the connector is not designed for, but something that can still be accommodated. There are two ways I can think of accomplishing this:

1) [standard approach] Set up selective sync for the connector. This is HubSpot's solution, and is recommended. It is also a nontrivial setup. The aim is to set up role hierarchies and set organization-wide defaults on objects the connector talks to in a way which hides undesired records from the integration user - the user whose Salesforce credentials are used for the integration. 

2) [homegrown, cooked-up-meth mad scientist solution] You could set the API names of custom fields differently on contacts than on leads, and have your field mappings only reflect lead-only fields. In practice, this is likely a nightmare. The connector would continue talking to standard fields on contacts, as discussed; you'd have different API names on objects for fields with similar labels, which is probably counterproductive for users and admins alike to navigate through; doing this could also result in increased API calls or sync errors - it's untested, and the sludgy byproduct of a badly-hypocaffeinated brain.

However you proceed, I strongly recommend getting a test portal from HubSpot (if you're a paying customer with support access, HubSpot Support can assist with this) you connect to the sandbox, and test as much as you possibly can. You may also want to speak with HubSpot consultants (either sales engineers at HubSpot itself, or third parties who specialize in these kinds of integrations - it's been several years since I've had a need for such a thing, but I could vouch for Bedrock Data back then).

[Edit: I haven't investigated closely enough for your use case, but software solutions like PieSync could potentially be a help here. Other high-powered API aggregators like Azuqua - something with more robust functionality than Zapier - could potentially work.]