Person Accounts confuse nearly every SFMC implementation team that encounters them. The questions are always the same: if we sync both the Account and Contact objects, are we counting the same person twice against our contact credits? What should the SubscriberKey be — the Account ID or the PersonContactId? Can we even query the Account synced DE for a send?

The answers are not obvious from the SFMC documentation and the consequences of getting them wrong are real — inflated contact counts that affect billing, or sendable DEs that create ghost duplicates in All Contacts. This guide maps out the data model clearly and gives you the correct patterns for querying, joining, and building sendable DEs from Person Account synced data.

What Person Accounts Actually Are in Salesforce CRM

A Person Account in Salesforce CRM is a merged object. It combines the Account and Contact objects into a single record that represents an individual person rather than a business. Under the hood, when a Person Account is created in CRM, Salesforce automatically creates both an Account record and a hidden Contact record. The Account record holds the person’s name and account-level fields. The hidden Contact record holds the person’s contact details and, critically, has its own 18-digit Contact ID — this field is called PersonContactId on the Account object.

This is the field that matters in SFMC. When MC Connect syncs Person Accounts, it recognises the PersonContactId as the unique identifier for the person, not the Account ID.

Does Syncing Both Account and Contact DEs Double-Count Contacts?

This is the question that causes the most anxiety. The answer is no — syncing both does not double-count, because MC Connect is smart enough to recognise that the Contact record linked to a Person Account is the same person. The Contact synced DE uses the 003 Contact ID. The Account synced DE also contains the PersonContactId field which is the same 003 ID. SFMC sees one unique Contact Key and counts one contact regardless of how many synced DEs that person appears in.

Building a Sendable DE for Campaigns Using Person Account Data

Synced DEs are not sendable directly. You cannot use them as a Journey entry source or send to them from Email Studio. You need to copy the data you need into a standard sendable DE using a SQL query in Automation Studio.

For Person Accounts, the Account DE is often the better starting point because it contains all the account-level fields you might need for personalisation — industry, custom fields, relationship data. But the send relationship in the output DE must be linked to PersonContactId, not the Account ID. The SQL below shows the correct join and field mapping:

/* Builds a sendable DE from Person Account data.
   Uses PersonContactId (003XX) as SubscriberKey — NOT the Account ID.
   Joins Account and Contact synced DEs to combine account-level and
   contact-level fields in one row.
   
   Target DE send relationship: SubscriberKey → Subscriber Key (Email Studio) */

SELECT

    /* This is the critical field — must be PersonContactId, not a.Id */
    a.PersonContactId              AS SubscriberKey,

    a.PersonEmail                  AS EmailAddress,
    a.Name                         AS FullName,
    c.FirstName,
    c.LastName,

    /* Account-level fields available in Account DE */
    a.Industry,
    a.BillingCity,
    a.AccountSource,

    /* Custom fields synced to Account DE */
    a.Tier__c                      AS CustomerTier,
    a.LastPurchaseDate__c          AS LastPurchaseDate

FROM   Account_Salesforce  a
JOIN   Contact_Salesforce  c
    ON  a.PersonContactId = c.Id    /* Join on PersonContactId = Contact.Id */

WHERE
    a.IsPersonAccount = true         /* Person Accounts only */
    AND a.PersonEmail IS NOT NULL   /* Ensure deliverable email exists */

Joining Account and Contact DEs for Query-Based Segmentation

For segmentation queries that do not need to produce a sendable DE — reporting, filtering, or joining to other objects — you can query either the Account DE or the Contact DE. When you need fields from both, join them on PersonContactId = Contact.Id as shown above. This join is always one-to-one for Person Accounts — each Account has exactly one PersonContactId.

If your segmentation query will ultimately produce a sendable DE, always output the PersonContactId as the SubscriberKey column regardless of which DE you start from. This is the only safe pattern.

Frequently Asked Questions