Changing a Deal Stage in HS without affecting Salesforce

[jlevy1]

Our client wishes to eliminate approximately 40 deal stages in a specific instance of their HS Portal. This portal, along with two others are synced with their Salesforce system. My question is two-fold...

1. Some of these deals are associated with contacts that exist in HS, so I need to change their deal stage prior to deleting it, correct? - If so, some of them are having me put a deal back to a previous stage... Does it let me do this?
2. Does anyone know how this may affect the SF integration if I delete the stage in HS? - Can't necessarily delete it in SF since other Business Units may be calling on these stages.

Any information/advice is greatly appreciated.

[bradmin · Accepted solution]

Hi, @jlevy1. Assuming the stages before exactly matched HubSpot and Salesforce, and the revised stages will be exactly the same, this is an easier task if you make the picklist value changes in Salesforce. 

Salesforce will let you rename, replace, or delete picklist values in their UI. The rename or delete is easy; records are resynced, and either their renamed value appears, or is removed entirely, respectively. In the case of a rename, I strongly recommend changing the API name of the value to exactly match the newly-changed label.

When you replace a value, the changed value will switch with the desired change. All impacted records should be resynced, regardless what choice you make. 

There's one last option on the Salesforce side, deactivating a picklist value. This will effectively sunset the value, but will still allow records to sync; however, if you attempt editing the record, you'll need to select an active value before you can proceed. This isn't a great setting for the connector, as you could have legacy records on either side with deactivated values. On its own, it's a viable solution, but it can make integrating with other platforms challenging. 

If you don't have an inclusion list or many records which have sync errors, I'd just replace, rename, or remove any picklist changes on the Salesforce side. Come back to HubSpot and refresh that particular mapping afterwards. (Even when you remove values from a picklist, its mapping still requires a refresh, same as if you'd added values.)

As a final step, you may want to inspect the HubSpot contact property after everything finishes resyncing. If there are any legacy values on the HubSpot picklist (which would only occur with records not on the inclusion list, or sync errors), you can fix those with imports or manually resolve. 

[jlevy1]

This is a great explanation, however, what I can't seem to get past is what if the Salesforce instance is used by multiple Business Units? I don't think I can delete or modify these without unintentional modifications to other uses of the pick list...  Am I just not understanding how SF handles this?

Thank you.

[bradmin]

I sort of described how things are in a vacuum; what you're asking about is more of a practical consideration, and a very real one some organizations need to deal with. 

Relabeling, removing, or deactivating picklist choices can have an adverse impact on the rest of the organization, if they're all using the same values. [Organizations using record types in Salesforce, on objects the connector talks to, have an advantage - you can customize which profiles see which picklist choices, on a picklist-by-picklist basis for each record type.]

If you're not using record types in Salesforce - and I absolutely would not start using them, just because of this use case - then you'll have a couple of different options: 

1) HubSpot-side workflows which changes an undesired value into a desired value. While a scheme like this could work, you need to take care that you're not changing a value set by some other business unit, into some value that's no longer meaningful to that business unit. 

2) Salesforce-side validation. You could set it up so that only the integration user has the ability to set those values, or prevent users from specific business units from setting some values. This has the sort of specificity you want, but may not scale. 

3) Helper/carbon copy fields. I'm not crazy about doing stuff like this, but some organizations create duplicates of picklists, and customize values that way,. in lieu of using record types or other validation. It does work, but also doesn't scale well. If you can limit doing this with one or two key picklists, that should be enough. 

If your organization does have multiple business units, and all use leads or contacts or accounts in some compartmentalized way, specific to just their business unit, it may be worth it to use record types in Salesforce. Otherwise, the occasional helper field and some additional Salesforce validation/HubSpot automation should give you some sort of workable solution. 

[edjusten]

Thank for your insight and expretise @bradmin!