{"title":"Using Person Accounts with StoreConnect","slug":"person-accounts","url":"https://support.storeconnect.com/articles/person-accounts","url_markdown":"https://support.storeconnect.com/articles/person-accounts.md","subtitle":null,"summary":"Configure StoreConnect for Salesforce orgs with Person Accounts enabled, including sync user profile setup, record conversion flows, duplicate rule exclusions, and data mapping considerations.","type":"Help_Documentation","video_url":"","keywords":"person accounts, Salesforce, sync user, record type, flow, after-update flow, duplicate rules, DUPLICATES_DETECTED, INVALID_PERSON_ACCOUNT_OPERATION, account contact merge, business account, contact linking, account credit, custom data mapping, pc fields, PersonEmail, profile clone, login as customer","last_modified":"2026-09-16T07:15:50+0000","body_markdown":"Use this topic to configure StoreConnect for a Salesforce org that has Person Accounts enabled. Person Accounts is a Salesforce feature that merges the **Account** and **Contact** objects into a single record representing an individual person rather than a business. StoreConnect works with Person Account orgs, but the setup steps below have to be completed before customers start registering or ordering.\n\n## Before you begin\n\n- Your Salesforce admin needs to complete this configuration. It involves profile record types, Flows, and duplicate rules.\n- The StoreConnect sync user must already exist. See [set up a StoreConnect sync user](how-to-create-a-storeconnect-sync-user).\n- Have your Person Account record type ID and the sync user's ID and alias to hand. Each is referenced by the configuration below.\n\n## How StoreConnect creates records in a Person Account org\n\nStoreConnect does not create Person Account records directly. When a customer registers or places an order, it creates records in this fixed sequence:\n\n1. Creates the **Contact**.\n2. Creates a standard business **Account**. A Person Account record type cannot be assigned at this point, because Salesforce requires a linked **Contact** first.\n3. Links the **Contact** to the **Account**.\n4. A Flow you create converts the **Account** to a Person Account.\n\nSteps 1 to 3 happen automatically. Step 4 only works if your org is configured in advance.\n\nBecause the **Contact** does not exist on the **Account** at step 2, Salesforce cannot apply a Person Account record type during insert, regardless of any before-insert flow or profile record type configuration. The conversion has to happen after step 3, once the **Contact** relationship is established.\n\nFour configuration tasks are required:\n\n| Step | Task                            | Purpose                                                                                     |\n| ---- | ------------------------------- | ------------------------------------------------------------------------------------------- |\n| 1    | Configure the sync user profile | Grants the sync user access to the Person Account record type                               |\n| 2    | Create an after-update flow     | Triggers the conversion once the Contact to Account link is established                     |\n| 3    | Order other flows correctly     | Prevents errors from flows that reference Person Account fields before the conversion fires |\n| 4    | Add duplicate rule exclusions   | Prevents the sync user from being blocked when creating records that match existing ones    |\n\nComplete them in order. Task 2 depends on the record type access granted in task 1.\n\n## Setup requirements\n\n### 1. Configure the sync user profile\n\nStoreConnect uses a dedicated Salesforce sync user to create and update records. For Person Accounts to work, that user's profile must have the Person Account record type available on the **Account** object.\n\nIf your sync user is on Salesforce's standard **Minimum Access - Salesforce Integration** profile (or a similar API-only profile), the **Account** object's record type settings are not editable through the standard profile interface. The **Enhanced Profile User Interface** setting controls access to that page and is locked on these profile types by default. Clone the profile first if you need to edit it.\n\nFor instructions on configuring record types for the sync user, see [set up a StoreConnect sync user](how-to-create-a-storeconnect-sync-user).\n\n### 2. Create an after-update flow to convert the account to a Person Account\n\nBecause StoreConnect creates a business **Account** first, you need a Salesforce Flow to convert it to a Person Account once the **Contact** is linked.\n\nConfigure the flow as follows:\n\n- **Object** — **Account**\n- **Trigger** — record-triggered flow, after update (not before insert)\n- **Entry condition** — detect when the **Contact** has just been linked by the StoreConnect sync user. For example, `PersonContactId` changed from null to a value, and `$User.Id` equals the sync user ID.\n- **Action** — update the **Account** record's `RecordTypeId` to your Person Account record type ID\n\n:::note\nThe after-update flow is required because Salesforce cannot apply the Person Account record type during an API insert; it must be set explicitly once the **Contact** is linked.\n:::\n\nTo confirm the flow works, place a test order on your store as a new customer, then check that the resulting **Account** record has the Person Account record type.\n\n### 3. Order other flows correctly\n\nIf your org has additional flows that act on Person Accounts (for example, welcome emails, entitlement assignment, or field updates), they must fire after the conversion flow completes. Flows that reference Person Account behavior and fire before the record type has been updated fail with `INVALID_PERSON_ACCOUNT_OPERATION` errors.\n\n1. Go to **Setup** \u003e **Flows**.\n2. Find any record-triggered flows on **Account** that reference Person Account fields or record types.\n3. Adjust their entry conditions or execution order so they run after the conversion flow.\n\n### 4. Handle duplicate rules\n\nIf your org has Salesforce duplicate rules on **Account** or **Contact** set to **Block**, the sync user hits `DUPLICATES_DETECTED` sync errors when StoreConnect tries to create a record that matches an existing one.\n\n:::warning\nDo not disable duplicate rules entirely. Add an exclusion for the sync user instead, so duplicate enforcement stays in place for everyone else.\n:::\n\n1. Go to **Setup** \u003e **Duplicate Rules**.\n2. Open each duplicate rule on **Account** and **Contact**.\n3. Add a condition of **Current User: Alias** equals the sync user's alias, and set the action to **Allow**.\n4. Save the rule.\n5. Confirm the exclusion works: place a test order using an email address that already exists in your org, and check the order syncs without a `DUPLICATES_DETECTED` error.\n\nFor more on managing duplicate records, see [automated lead conversion to avoid duplication](lead-contact-and-account-deduplication).\n\n## How StoreConnect matches existing Person Account records\n\nWhen a customer registers or checks out on a StoreConnect storefront, StoreConnect attempts to match them to an existing Person Account record by first and last name combined with either email or phone. If a match is found, it links the new login to the existing Person Account record rather than creating a new one.\n\n## Multi-business-unit orgs with Person Accounts\n\nIf your Salesforce org uses both Person Accounts and multiple business account structures (for example, separate accounts per division, region, or entity), there are additional considerations for how StoreConnect creates and matches records.\n\n### The matching risk\n\nStoreConnect's account-matching logic uses name, email, address, and phone to find an existing account. In an org with many accounts across different business units, a customer checking out could potentially be matched to an account in a different business unit if the matching fields overlap.\n\nThis is most likely to occur during guest checkout for customers who have existing records in your org but have not yet been assigned a StoreConnect ID.\n\n### Mitigations\n\n#### Record type defaults on the sync user profile\n\nAny **Account** or **Contact** created through StoreConnect uses the record type set as the default on the sync user's profile for that object. If your org has multiple **Account** record types for different business units, set the sync user's default to the record type appropriate for website-created records. See [set up a StoreConnect sync user](how-to-create-a-storeconnect-sync-user).\n\n#### Scoping existing records with per-record sync opt-in\n\nIf only a subset of your **Account** and **Contact** records should take part in StoreConnect matching and checkout, use [per-record sync opt-in](per-record-sync-opt-in) to mark those records explicitly. Records without opt-in are not matched during checkout, even if their email or name appears to match.\n\n#### Disabling automatic account linking\n\nIf your org's account structure makes automatic matching unreliable, you can turn it off using the **Enable Company Name** store variable. When active, StoreConnect skips account matching for guest checkouts and always creates a new **Account**. Logged-in customers are still linked to their existing **Account**. Contact StoreConnect support or your implementation partner to configure this.\n\n#### Duplicate rule exclusions\n\nIf your org has Salesforce duplicate rules set to **Block** on **Account** or **Contact**, add a sync user exclusion as described in [setup requirements](#setup-requirements) above. This prevents `DUPLICATES_DETECTED` errors without disabling your rules for all users.\n\n### Flow conditions for multi-business-unit conversion\n\nIf you use an after-update flow to convert accounts to Person Accounts (see [create an after-update flow](#2-create-an-after-update-flow-to-convert-the-account-to-a-person-account)), scope the entry condition to records that belong to the correct business unit, for example by checking the **Account** record's record type or a custom field that identifies the business unit. Without scoping, the flow fires on every **Account** the sync user creates, including business accounts for other divisions.\n\n## Account credits with Person Accounts\n\nAccount credits work with Person Accounts without any additional configuration. Behind every Person Account is both an **Account** and a **Contact** record, and StoreConnect's credit logic resolves through that chain to the Person Account's underlying **Account** record.\n\nKey points:\n\n- Account credits are per person, not shared across a household.\n- Create `Account_Credit__c` records against the Person Account's **Account**, not a parent household account.\n- Set `Can_Use_Account_Credit__c` to `true` on the Person Account's **Contact** side.\n- Set `Pay_By_Account__c` to `true` on the Person Account's **Account** if you use pay by account.\n\nHousehold-level shared credits are not supported. There is no setting for them. Sharing credits across household members requires custom logic and carries concurrency risk.\n\nSee [account credit](account-credit) and [pay on account at checkout](pay-by-account) for general configuration.\n\n## Custom data mapping with Person Accounts\n\nWhen Person Accounts is enabled, Salesforce automatically creates `__pc` suffix fields on the **Account** object that mirror **Contact** fields (for example, `PersonEmail`). These fields stay in sync with the underlying **Contact** automatically.\n\nMap your StoreConnect custom data mappings against the **Account** object using the `__pc` fields, not the **Contact** object or its `__c` fields. This matters most for read/write mappings, where StoreConnect needs to write data back to Salesforce. For read-only mappings the distinction is less critical, but using `__pc` on **Account** is still the consistent approach.\n\n:::warning\nDo not remap native StoreConnect fields; this causes them to sync as null. Use custom data mappings only for fields StoreConnect does not already handle natively.\n:::\n\nSee [add custom data fields to your store](liquid-custom-data-fields) for mapping instructions.\n\n## Log in as a customer\n\nThe log in as a customer feature lets Salesforce users browse the storefront as a specific customer. Before testing it in a Person Account org, confirm the sync user's profile has the Person Account record type available. See [set up a StoreConnect sync user](how-to-create-a-storeconnect-sync-user) for profile configuration details.\n\n## Setup checklist\n\n| Step | Who | Notes |\n| --- | --- | --- |\n| Add Person Account as an available record type on the sync user's profile | Salesforce admin | On a standard API-only profile, clone the profile first. These profiles do not support editing record types through the standard profile interface. |\n| Create the after-update flow to convert **Account** to Person Account | Salesforce admin | Must fire after the **Contact** is linked to the **Account**, not on insert |\n| Order other Person Account flows to fire after the conversion flow | Salesforce admin | Prevents `INVALID_PERSON_ACCOUNT_OPERATION` errors |\n| Add the sync user exclusion to duplicate rules | Salesforce admin | Prevents `DUPLICATES_DETECTED` sync errors |\n| Validate that existing customer email addresses align | Implementation | Ensures existing Person Accounts match on customer registration |\n\n## Verify the configuration\n\nOnce all four tasks are complete, place a test order on your store as a new customer, then confirm:\n\n- A Person Account record was created, not a separate business **Account** and **Contact** pair.\n- The **Account** record has your Person Account record type.\n- No `INVALID_PERSON_ACCOUNT_OPERATION` or `DUPLICATES_DETECTED` errors appear in the StoreConnect sync errors.\n\nThen repeat the test using an email address that already exists in your org, and confirm the order links to the existing Person Account rather than creating a new one."}