the data that comes through is name/email/address/Company.
I've created a some fields in SF to match what the marketing guys created in hubspot.
Lets take 1 example "Personas"
In SF this is a 5 item picklist field, Now i've just noticed that in hubspot its called Persona and i SF its called Personas, is that causing the issue?
I have other fields where everything appears to be matched up correctly that arent working.
In this case, unless your Salesforce picklist has internal values like "persona_5", nothing will show in Salesforce.
You might do better mapping that specific HubSpot picklist to a custom text field in Salesforce, then writing a formula field in Salesforce which displays a friendlier name (with a CASE() function, perhaps). While you could have a value-for-value Salesforce picklist, this specific HubSpot property has internal values that vary significantly from its labels.
This is one of those cases where you just have to get the data to Salesforce, then manipulate it the way you want. (Alternately, you could use a HubSpot workflow to pass a carbon-copy of the label to a custom text property in HubSpot. This text property could be mapped to a custom Salesforce field of whatever data type you prefer of text or picklists.)
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
The mapping's update rule will tell you what to expect with HubSpot-side changes, based on whether data already exists in Salesforce. If your Salesforce picklist already had a value, but the mapping's update rule is the default "Use Salesforce value unless blank", then whether persona_5 or any other value was added, nothing's going to get to Salesforce. Either the update rule would have to be changed to Always, or the value would have to be cleared out from Salesforce, then resynced from HubSpot.
I strongly suspect you have custom configuration around your field-level security and object permissions. I've asked about this several times between the two threads, and haven't received much of a response. It feels a lot like the integration user's profile may not have full read-write permissions on the object, as well as every field on every object the connector talks to. This is absolutely a best practice for the connector, and if there's a deviation from that, it could explain some of the things you've been seeing.
If at all possible, a default System Administrator profile (or a cloned profile with full read-write permissions on all objects and all fields the connector talks to) should be used for the integration.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
I will need to check that out. I didnt do the deployment of SF, so am still getting to grips with some of the bespoke configs and i've never used hubspot before and there's not much info coming from the company we're using on how they've set it up.
I did the integration and I'm the full sys admin, so there shouldnt be any issues from that.
You're saying that your Salesforce user is the integration user, and that user record is using the default, out-of-the-box System Administrator profile? If so, can you screen shot what the mapping looks like from your mappings page?
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
So when I create a lead on HS, it comes through to SF and the lead owner and creator is listed as me and I'm the sys admin and yes the sys admin profile is the out of the box one.
It looks like the same property is reused on both sides of the mapping, and that would explain why you're seeing what you're seeing. The "__c" syntax appears for both the HubSpot property and the Salesforce field in the mapping.
Custom HubSpot properties - unless you have personally edited them yourself to match - do not have this same naming convention.
You'll want to update that mapping to use the default HubSpot Persona property, mapped to your custom Personas picklist in Salesforce. (It's entirely possible both of those property labels are duplicated. HubSpot, unfortunately, does not require unique labels to save properties, only unique names. If you inspect the page HTML while updating the mapping, that should show you the actual property value being used, with or without the "__c".)
This is a gigantic pain for the integration, and one of my pet peeves about how HS and SF work together, especially for properties with duplicate labels. It sounds like this may be the culprit here.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
looks like the same property is reused on both sides of the mapping, and that would explain why you're seeing what you're seeing. The "__c" syntax appears for both the HubSpot property and the Salesforce field in the mapping.
I'm assuming that was the HS guy, that but i'll check
Custom HubSpot properties - unless you have personally edited them yourself to match - do not have this same naming convention.
Ultimately I havent edited anything in HS (not allowed ) so will need to get the HS guy to do that
You'll want to update that mapping to use the default HubSpot Persona property, mapped to your custom Personas picklist in Salesforce. (It's entirely possible both of those property labels are duplicated. HubSpot, unfortunately, does not require unique labels to save properties, only unique names. If you inspect the page HTML while updating the mapping, that should show you the actual property value being used, with or without the "__c".)
This is a gigantic pain for the integration, and one of my pet peeves about how HS and SF work together, especially for properties with duplicate labels. It sounds like this may be the culprit here.
Is it worthwhile maybe starting this again, i.e. delete all custom fields on both sides and then have a clear naming convention?
At this point we're still testing so there's no issue with data loss
Killing and restarting the integration is a last-ditch effort, and I don't think that's necessary yet. I would, however, review your mappings, and replace any ones where it looks like the HubSpot side of the mapping is erroneously using the Salesforce field. Those mappings are inert, and will never sync anything, until the HubSpot-side property has been restored.
Repairing mappings, and/or resyncing records (assuming you have the API calls to do so) should get any missing mapped info over to Salesforce.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
One extra connector behavior to look out for, @keithplunkett (also filed to Integration Pet Peeves) is: any time you have a picklist mapped from Salesforce, and you add net-new picklist choices on the Salesforce side, you'll need to manually refresh the mapping itself, to account for the new value(s).
So, that 'persona_5' picklist value added on the Salesforce side would need to have its mapping refreshed first in HubSpot, then records resynced second. My apologies for not listing that originally, and could explain why the attempted resync hadn't worked.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.
Hi, @keithplunkett. Unlike Salesforce picklists, HubSpot picklists have a label-value pair; the label appears in the UI, but the value is required to make integrations and custom development work.
Go to the Personas property in HubSpot from the Contacts Properties screen, and ensure the Salesforce picklist it's mapped to has picklist values which exactly match the HubSpot property's values, not their labels. A Salesforce picklist matching HubSpot picklist labels won't sync, but will once it matches their values.
Sometimes, the value that's stored on the HubSpot picklist is something unfriendlier than the label. Additional Salesforce manipulation of the value may be required.
Brad Mampe, Salesforce Analyst, Fidelity I'm probably wrong. I may not be right about that.