> ## Documentation Index > Fetch the complete documentation index at: https://docs.fusioncore.us/llms.txt > Use this file to discover all available pages before exploring further. # Using the Primary Account Field > Point an individual's orders, opportunities, and statements at an organization by setting the Primary Account on their Person Account. ## Overview A Person Account is its own Account, so by default everything an individual buys is assigned to that Person Account. **Primary Account** lets you redirect that: set it to an organization, and fusionCore assigns the individual's orders, opportunities, and statements to the organization instead — while the individual stays the contact on the record. This suits the common case where a person is affiliated with a company that does the paying: an employee of a member firm, a student at a member institution, a staff member of a chapter. > [!NOTE] > > **Primary Account** (`FC_Primary_Account__c`) is a lookup on **Contact**, shipped by the unmanaged **fusionCore Person Accounts** package. On a Person Account it surfaces as `FC_Primary_Account__pc`, which is what appears on the Person Account layout. ## Prerequisites * Person Accounts are enabled and configured — see [Set Up Person Accounts](https://docs.fusioncore.us/end-user-guides/accounts/person-account-support/person-account-set-up/index.md). * The **fusionCore Person Accounts** package is installed. Without it, fusionCore falls back to assigning records to the Person Account itself. * The organization you want to point to exists as a business Account. * You have a permission set that grants edit access to the field — see [Who Can Set It](#who-can-set-it). ## Set the Primary Account **1. Open the Person Account** Find the individual on the **Accounts** tab and open their Person Account record. **2. Set Primary Account** Set **Primary Account** to the organization that should own this person's orders, opportunities, and statements. Leave it blank to keep everything on the Person Account itself. > [!WARNING] > > Point this at a **business** Account, never at another Person Account. fusionCore does not stop you — the validation that would have enforced it was dropped from this release — so an incorrect value simply assigns records to the wrong place, quietly. **3. Save** Click **Save**. The change applies to records created **from now on**; see [What It Does Not Change](#what-it-does-not-change). ## How fusionCore Resolves the Account Every time fusionCore needs the Account for an individual, it applies the same rule: **1. Are Person Accounts enabled, and is the field installed?** If Person Accounts are off, or the **fusionCore Person Accounts** package is not installed, the Account is used exactly as before. The add-on is checked at run time, so Commerce works with or without it. **2. Is Primary Account populated?** If it is blank, the individual's own Person Account is used. **3. Otherwise, use the Primary Account** The record is assigned to the organization in **Primary Account**. This applies whether fusionCore starts from the Person Account or from its Person Contact — both routes reach the same answer. ## What It Affects | Record | Behavior | | - | - | | **Order** | An order created for an organization will list the Primary Account in the account field. The individual remains the **Bill To Contact** | | **Opportunity** | Same — the opportunity's Account becomes the Primary Account, with the individual as the contact | | **Statement** | A statement raised for an organization is assigned to the Primary Account. | | **Customer Type** | Unchanged. A Person Account still appears when the value is `Individual`, which is what keeps the Person Account/Contact's name on the customer fields. `Organization` will make this the Account | > [!NOTE] > > Because **Customer Type** stays `Individual`, the customer fields (`FS_Customer__c`, `FS_Customer_Name__c`, `FC_Statement_Customer__c`) keep showing the **person's** name, not the organization's. The organization is who the record is filed under; the individual is still who it is about. ## What It Does Not Change * **Records created before you set it.** Existing orders, opportunities, and statements keep the Account they were created with. Reassign them by hand if you need to. * **The Person Account itself.** It remains a full Account and can still be reported on and acted on directly. * **Membership or benefits.** Subscriptions and benefit allocations continue to belong to the individual. * **Portal access.** The individual's Experience Cloud access is unaffected. ## Who Can Set It The two permission sets shipped with the package treat this field differently — the only place they differ: | Permission set | Primary Account | | - | - | | `FS Person Account - Manage Business Data` | Read and **edit** | | `FS Person Account - View Business Data` | Read only | Give staff who maintain these affiliations the **Manage** permission set; **View** is enough for everyone who only needs to see where a person's records are filed. See [Assign Permission Sets for Person Account Access](https://docs.fusioncore.us/end-user-guides/accounts/person-account-support/person-account-set-up/index.md#assign-permission-sets-for-person-account-access). ## Limitations and Common Pitfalls with the Primary Account field * **Nothing validates what you point at.** A Primary Account set to another Person Account, or to an unrelated organization, is accepted and silently misfiles every new record. Check the value when you set it. * **It is not retroactive.** Setting or clearing the field never moves records that already exist. * **The field must be visible before it can be set.** Without one of the permission sets, and without the field on the Person Account layout, staff cannot populate it — the field appearing blank is not the same as it being blank. * **Without the add-on package there is no fallback to configure.** Commerce checks for the field at run time; if it is absent, everything is assigned to the Person Account and no error is raised. * **The customer name still shows the individual.** If you expected the organization's name on the order, that is not what this field does — it changes the Account, not the customer. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.