4

We are connecting Marketing cloud and SF orgs. In Salesforce org we have leads and person accounts. When we connected both environments, We see that we have contacts and accounts as different objects instead of one in MC sync option for Data Sources.

Now my questions is for data extensions which object should i refer to? account or contact?

6

You will need only Accounts, not contacts. All relevant fields from the contact will be available there.

The following points are worth noting when working with PersonAccounts:

  • Synced PersonAccount records are not automatically added to the Marketing Cloud contact count. Salesforce contacts are. So with accounts you actually have better control of your billable contact count.

  • The relationship with the Marketing Cloud subscriber/contact model is established with the field PersoncontactId. You need to remember this when you create sales cloud entry events in journey builder.

  • Custom contact fields will have the ending __pc

  • Salesforce AMPscript functions based on contact fields will work on either the contact or account object. For consistency with Salesforce functionality and overall understanding it would be better to use accounts.

  • there is hardly any documentation on those and other behaviour aspects of PersonAccounts for the Marketing Cloud

5
  • Hello @Stephen de Paly Thanks for your answer. "HasOptedOutOfEmail" field is not available on account object this standard field is only available on the contact object. So how i can manage the subscription and unsubscription.
    – Marc
    Aug 30 '19 at 2:52
  • You'll find that information on a PersonAccount in the field PersonHasOptedOutOfEmail, it is the same as information in contact field HasOptedOutOfEmail. Aug 30 '19 at 8:56
  • Thanks Stephan and Bjorn :) I am good now
    – Marc
    Aug 31 '19 at 14:31
  • @marc you're welcome Aug 31 '19 at 14:52
  • @StephandePaly, appreciate your input, but the "you need to remember this" of point #2 - is a no go for us - not clean enough as you never know who will use the system in the future. As for point #1 which is 100% valid - in my opinion - billable issues shouldn't drive Data Considerations. In this case a recommendation to create a Custom Object as a workaround to avoid Contact Billing would be the standard on any SFMC account.
    – LimeWeb
    May 21 at 16:44
-1

I believe it's a matter of flavor.

For consistency and especially to keep things intuitive for any future SFMC user - Our practice is to use Contacts - and avoid using Accounts altogether- then roll-up any field you need from Account to the Contact level in the CRM. There are usually not many, and it takes a minute when you need a new field roll-up.

This also ensures that the conversion Lead >> Contact is consistent.

In other words our recommendation and practice is to avoid marketing to Accounts. Technically, if you go the other way - when you use PersoncontactId - you are marketing to Contacts anyway.

If Contact billing limits is a concern - create a Boolean field on Contacts "Sync_to_sfmc" and filter based on that with CRM logic to control billing.

Also, don't forget you always have the option to JOIN on Accounts instead of rolling up fields in the CRM.

1
  • @StephandePaly, would appreciate your opinion on this suggested architecture.
    – LimeWeb
    May 21 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.