Hi, @MichaelH. It's not technically required, but I urge you as strongly as possible to keep consistent API names between leads and contacts.
One of the reasons the connector handles this use case easily is because there's a related HubSpot Intelligence record on the lead or contact the HubSpot contact is syncing to. The HSI record knows whether HubSpot is talking to a Salesforce lead or contact, so it won't matter whether we're trying to pass $Lead.Field_Name__c or $Contact.Field_Name__c; the Field_Name__c designation applies, regardless the object.
If, instead, you had $Lead.Field_Name__c and $Contact.Slightly_Different_Field_Name__c, you could manage it, but you'd need to create two mappings in HubSpot: one for Field_Name__c, and another for Slightly_Different_Field_Name__c. You'd also need to ensure all fields with discrepancies in naming convention are mapped properly in the Map Lead Fields menu in Salesforce.
These kinds of inconsistencies require more planning and maintenance than simply keeping the API name of custom mapped fields the same, across Salesforce leads and contacts.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
Hi, @MichaelH. It's not technically required, but I urge you as strongly as possible to keep consistent API names between leads and contacts.
One of the reasons the connector handles this use case easily is because there's a related HubSpot Intelligence record on the lead or contact the HubSpot contact is syncing to. The HSI record knows whether HubSpot is talking to a Salesforce lead or contact, so it won't matter whether we're trying to pass $Lead.Field_Name__c or $Contact.Field_Name__c; the Field_Name__c designation applies, regardless the object.
If, instead, you had $Lead.Field_Name__c and $Contact.Slightly_Different_Field_Name__c, you could manage it, but you'd need to create two mappings in HubSpot: one for Field_Name__c, and another for Slightly_Different_Field_Name__c. You'd also need to ensure all fields with discrepancies in naming convention are mapped properly in the Map Lead Fields menu in Salesforce.
These kinds of inconsistencies require more planning and maintenance than simply keeping the API name of custom mapped fields the same, across Salesforce leads and contacts.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
Just out of curiosity based on the reply above, if there is a scenario where we are using a out the box field (standard SF field) and a new custom field on one of the objects, what would be the best practice? Both Lavels are the same but the API Names and values dffer.
Example:
Lead - StandardField- Label Custom Field
Type Picklist / Dropdown Select
Values X,Y,Z
Contact - Stnadard_Field__c - Label Custom Field
Values A,B,C,D,E,F,G
Type Picklist / Dropdown Select
Would we have to create 2 HubSpot properties created as a placeholder for each field and have each property mapped to the relevant field in Salesforce, or would we have 1 Hubspot property which contains both sets of values and have 2 mappings?
I recommend changing the label on the custom field so that it's unique from the standard field. While HubSpot won't have issues writing to either, you only see the field label in the UI. You'd have to inspect the page HTML to know which value you wanted to use. This isn't a great experience and is prone to errors.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
Thanks for the response, can you confirm which apporach would be best? Either 2 hubspot properties and 2 mappings, or 1 consolidated hubspot property with 2 mappings?
You'll want two distinct mappings for this. If you map multiple Salesforce fields to the same property, an update to one Salesforce field could update the other, depending on the mapping rule. Even without that, it could be tough to determine which field triggered the change.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.