Not updating Converted Contacts in Marketo

Tara_Rowe
Level 5

Not updating Converted Contacts in Marketo

We started receiving a error in Marketo related to SFDC

SFDC Error:

FIELD_INTEGRITY_EXCEPTION: A country/territory must be specified before specifying a state value for field: State/Province\n

exceptionMessage:

FIELD_INTEGRITY_EXCEPTION: A country/territory must be specified before specifying a state value for field: State/Province\n

It turns out that we cannot write into the field as they turned it into a read only, we now can only update on the contact mailing address.

In further discussion it was brought up that we need to stop updating converted contacts in Marketo. Although we use to update contacts previously, changes were made where a contact is associated to a account even if they are a lead. This means going through our instance and finding any sources that might be updating these records. Anyone have best practices out there on dealing with SFDC contacts with Marketo. It seems odd to me that we are not updating these records?

1 REPLY 1
Andrea_Lechner
Level 2

Re: Not updating Converted Contacts in Marketo

When a person is a lead in SFDC, they have a lot of company-level data associated to them, like number of employees and address information. When those leads convert to contacts, some people believe that you should stop updating any company-related details on the contact, because it leads to data disparity. Now that sounds better in theory than practice. For example, if someone works remotely in Arizona for a company headquartered in New York, and you are an event coordinator in charge of inviting people in AZ to an event, would you rather have EVERYONE who works for the NY company with NY in "State" on their record, or AZ? You could certainly argue AZ on the person, would be better.

However, if you think about a field like "Number of Employees" having 1-10 on a person's record, because that's what they selected on a form, while the account has 5000-10000, makes a lot less sense.

Ultimately, I'd advise to consider FIELD-LEVEL read/write access, opposed to OBJECT-LEVEL restrictions.