Does HubSpot update locked Salesforce fields?

SOLVE
Highlighted
New Contributor

I have a few fields in SFDC that I don't want HubSpot to update once they've been previously set. For example, once a contact's lead type is set as either "Inbound" or "Outbound" following a form submission, I don't want this to ever change, regardless of any future workflows they might pass through. Is there a way to do this?

Reply
0 Upvotes
1 Accepted solution

Accepted Solutions
Esteemed Advisor

Hi, @SigstrHub. To answer the explicit question asked in the subject, HubSpot won't update fields in Salesforce it doesn't have permission to write to. However, that's a little different than the use case you asked about. I'd use some sort of Salesforce-side automation to resolve the issue. 

 

You can accomplish this one of two ways: with validation, or with workflow/Process Builder automation. If you were to write a validation rule (say. the lead type was nonblank and changed to something else). When HubSpot tried to sync to Salesforce and change the lead type, the validation error would throw, preventing the change. However, this will result in a sync error, and probably isn't a desirable way to resolve those kinds of conflicts, unless the use case is very low. 

 

A better approach involves writing Salesforce workflow or Process Builder rules. When the prior lead type is nonblank and changes, the automation can change this back to its prior choice. (If we're talking about a picklist here, workflow rules will only allow you to explicitly choose a picklist choice; if you have to dynamically suggest a choice, you'll want to use Process Builder instead.)

 

A more manageable approach may involve mapping lead type to a helper field in Salesforce, then using automation to only change the desired field when you want. For example, you could write a workflow rule which says "the prior choice of the helper field is blank, and the current choice is nonblank". When this use case occurs, the helper field choice is copied to the desired field. That way, HubSpot can send as many changes as it wants to the helper field, but the desired field is only updated once, via your Salesforce workflow.   


Brad Mampe, Salesforce Analyst, Fidelity
I'm probably wrong. I may not be right about that.
Reply
0 Upvotes
1 Reply 1
Esteemed Advisor

Hi, @SigstrHub. To answer the explicit question asked in the subject, HubSpot won't update fields in Salesforce it doesn't have permission to write to. However, that's a little different than the use case you asked about. I'd use some sort of Salesforce-side automation to resolve the issue. 

 

You can accomplish this one of two ways: with validation, or with workflow/Process Builder automation. If you were to write a validation rule (say. the lead type was nonblank and changed to something else). When HubSpot tried to sync to Salesforce and change the lead type, the validation error would throw, preventing the change. However, this will result in a sync error, and probably isn't a desirable way to resolve those kinds of conflicts, unless the use case is very low. 

 

A better approach involves writing Salesforce workflow or Process Builder rules. When the prior lead type is nonblank and changes, the automation can change this back to its prior choice. (If we're talking about a picklist here, workflow rules will only allow you to explicitly choose a picklist choice; if you have to dynamically suggest a choice, you'll want to use Process Builder instead.)

 

A more manageable approach may involve mapping lead type to a helper field in Salesforce, then using automation to only change the desired field when you want. For example, you could write a workflow rule which says "the prior choice of the helper field is blank, and the current choice is nonblank". When this use case occurs, the helper field choice is copied to the desired field. That way, HubSpot can send as many changes as it wants to the helper field, but the desired field is only updated once, via your Salesforce workflow.   


Brad Mampe, Salesforce Analyst, Fidelity
I'm probably wrong. I may not be right about that.
Reply
0 Upvotes