> ## 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. # NPC Stakeholder Management > Drive fusionCore's Primary Account, Primary Contact, and Billing Contact from Account Contact Relationships, with two-way sync and one holder per Account. ## Overview Salesforce Nonprofit Cloud (NPC) models each individual as a **Person Account** and each organization as a business Account, and links them through **Account Contact Relationships** (ACRs). That gives you many-to-many relationships out of the box — but two gaps make ACRs awkward to build on: * **NPC puts no limit on how many organizations a person can call primary.** Nothing stops several relationships all claiming to be the primary one. * **The standard Active, Start Date, and End Date fields don't affect each other.** Checking Active does not date the relationship, and dating it does not activate it. The **NPC Stakeholder Management** accelerator closes both gaps and makes those relationships the place you manage fusionCore's key roles: which organization is a person's **Primary Account**, and which person is an organization's **Primary Contact** and **Billing Contact**. It works in both directions. Flag the relationship and the Account field updates; set the Account field and the accelerator flags the matching relationship — creating and activating it if none exists. Either way, each Account ends up with exactly one holder of each role, which is what lets fusionCore put orders on the right Account. This accelerator is not installed by default with fusionCore — it's an add-on package installed separately. > [!NOTE] > > The current version verified against source is 1.0.0. Confirm the version installed in your org before relying on details below. ## Key Concepts Three roles, each a flag on the relationship paired with a field on an Account: | Relationship flag | Account field | On which Account | | - | - | - | | **Is Primary Group** (`IsPrimaryGroup`) | **Primary Account** (`FC_Primary_Account__pc`) | The **Person Account** that owns the relationship's Contact | | **Is Primary Member** (`IsPrimaryMember`) | **Primary Contact** (`FCORE_PAY__Primary_Contact__c`) | The **business Account** on the relationship | | **Is Billing Contact** (`FC_Is_Billing_Contact__c`) | **Billing Contact** (`FCORE_PAY__Billing_Contact__c`) | The **business Account** on the relationship | * **Is Primary Group** and **Is Primary Member** are two distinct standard Salesforce fields that fusionCore gives meaning to — not the generic `IsPrimary` field. **Is Billing Contact** is added by this accelerator. * **Primary Account** comes from the [fusionCore Person Accounts](https://docs.fusioncore.us/end-user-guides/accounts/person-account-support/index.md) package. It is what files an individual's orders, opportunities, and statements under an organization. * **One holder per Account.** Flagging one relationship clears the flag on the others for that Account. Attempting to set two in a single save is rejected. * **Active drives the dates.** Checking **Active** sets **Start Date** to today; unchecking it sets **End Date** to today. > [!WARNING] > > **Primary Member** and **Is Billing Contact** describe a person's role at an *organization*, so they cannot be set on a relationship whose Account is a Person Account — and **Primary Contact** and **Billing Contact** cannot be set on a Person Account itself. Both attempts are rejected with a message explaining that the fields apply to business Accounts only. ## Prerequisites * **Contacts to Multiple Accounts** is enabled in the org. This is what activates the Account Contact Relationship object and its UI — without it, there is nothing for the accelerator to work on. * **Person Accounts** are enabled, and the **fusionCore Person Accounts** package is installed — it ships the **Primary Account** field that this accelerator keeps in sync. * The **Related Accounts** related list is on your Person Account layout and **Related Contacts** is on your business Account layout, so staff can reach relationships from either side. * Staff who maintain these relationships need access to the **Primary Account** field on the Person Account. See [Set Up Person Accounts](https://docs.fusioncore.us/end-user-guides/accounts/person-account-support/person-account-set-up/index.md). * **Both NPC and Stakeholder Management** have been installed and set up in your org > [!NOTE] > > Salesforce's **Stakeholder Management** accelerator is optional and sits alongside this one. It adds a **Create Relationship or Affiliation** quick action, **Mark as Primary** and **Mark as Former** buttons, relationship charts, and separate list views for active and inactive relationships. This accelerator works with or without it — it watches the relationship's fields, not the UI that sets them. ## How to Configure **1. Assign the Account Contact Relationship layout** The package ships **FC Account Contact Relationship Layout**, which surfaces the three role flags together with **Roles**, **Active**, **Start Date**, and **End Date**. Assign it to the profiles that maintain relationships, or add those fields to your own layout — the automation runs regardless, but staff cannot set what they cannot see. **2. Grant field access** Assign one of the two shipped permission sets to anyone who works with relationships: * `FC NPCSM Manage Business Data` — read and **edit** **Is Billing Contact**. * `FC NPCSM View Business Data` — read only. **Is Primary Group** and **Is Primary Member** are standard fields, so their access follows your existing profile and permission-set setup rather than these permission sets. **3. Expose Primary Contact and Billing Contact on the Account layout** Add **Primary Contact** and **Billing Contact** to your **business Account** page layouts so staff can set a role from the organization's record instead of hunting through relationships. Leave both off the Person Account layout — they do not apply there. **4. Confirm the trigger units are enabled** The accelerator registers twelve trigger units — eight on Account Contact Relationship and four on Account — and all ship enabled. To review or disable one, go to **Setup → Custom Metadata Types → Trigger Unit → Manage Records** and look for the records prefixed `NPCSM`. **5. Clean up existing relationship data** If relationships were loaded before you installed the accelerator, more than one may already carry the same flag for an Account. Query for duplicates and reduce each Account to a single holder per role before staff start relying on the fields. > [!WARNING] > > Where multiple relationships already carry a flag, the accelerator keeps one and clears the rest — but which one it keeps is not defined. Resolve duplicates deliberately rather than letting the automation choose. ## Where Staff Create Relationships How a relationship gets created depends on whether your org has Salesforce's Stakeholder Management accelerator installed. Either route produces an ACR the accelerator then keeps in sync. | | NPC on its own | With Stakeholder Management | | - | - | - | | How a relationship is created | **Add Relationship** on the Account's related list | The related list, or the **Create Relationship or Affiliation** quick action | | Setting Start Date and End Date at creation | Only if those fields are on the ACR layout | The quick action collects them | | Telling active from former relationships | Not distinguished in list views | Separate active and inactive list views | | Deactivating a relationship | Through the list view | **Mark as Former** button | > [!WARNING] > > Two known traps in Stakeholder Management's relationship flow, neither of them caused by this accelerator: > > * **The flow can rename the organization.** Creating the first relationship between a Person Account and an organization has been observed renaming that organization to "*\*'s Household" — even when it already had a name and was not a household. Check the organization's name after using the quick action, or create the relationship from the related list instead. > * **A duplicate relationship fails silently.** Because only one relationship can exist per Account-and-Contact pair, creating one that already exists throws an error with no message. Check the existing relationships before adding one. > [!NOTE] > > If your staff use **Mark as Primary** or **Mark as Former**, confirm which fields those buttons set in your org. This accelerator responds to **Is Primary Group**, **Is Primary Member**, **Is Billing Contact**, and **Active** — a button that sets a different field will not trigger the sync. ## How the Sync Behaves > [accordion] Setting a flag on the relationship > > Checking **Is Primary Group**, **Is Primary Member**, or **Is Billing Contact** writes the relationship's Contact (or its Account, for Primary Group) to the paired Account field, and clears the same flag on every other relationship for that Account. > [accordion] Setting the field on the Account > > Setting **Primary Account**, **Primary Contact**, or **Billing Contact** finds the matching relationship and flags it. If no relationship exists for that Account and Contact, one is created. Either way the relationship is activated: **Active** is checked, **Start Date** becomes today, and an **End Date** in the past or today is cleared. A **future** End Date is left alone. > [accordion] Changing a role from one person to another > > The accelerator clears the outgoing holder before setting the incoming one, so the org never briefly holds two primaries. You do not need to un-flag the old relationship first. > [accordion] Checking or unchecking Active > > Checking **Active** sets **Start Date** to today and clears **End Date** if it is today or in the past — a future End Date persists. Unchecking **Active** sets **End Date** to today. A relationship that is not active does not hold a role, even if its flag is still checked. > [accordion] Deleting the relationship that holds a role > > Deleting an active relationship clears whichever role it held — **Primary Account**, **Primary Contact**, or **Billing Contact** — so no Account field is left pointing at a relationship that no longer exists. ## Limitations and Common Pitfalls with NPC Stakeholder Management * **Duplicate flags in loaded data are resolved arbitrarily.** If several relationships already carry the same flag for one Account, the accelerator keeps one and clears the others with no rule for which. Clean the data up yourself before go-live. * **Setting two holders in one save is rejected.** Loading or editing two relationships that both claim the same role for the same Account fails the whole transaction — the message names which role. Split the change into separate saves, or set only the winner. * **A flag on an inactive relationship does nothing.** The role goes to an active, flagged relationship. Un-checking **Active** gives up the role even though the flag stays checked. * **The Person Account fields are the mirror image of the business Account fields.** Primary Account belongs to the Person Account; Primary Contact and Billing Contact belong to the organization. Setting either pair on the wrong kind of Account is rejected. * **Without the fusionCore Person Accounts package there is no Primary Account field to sync.** Install it first, or the Primary Group half of the accelerator has nothing to write to. * **A Person Account's household Account is not treated as a default.** If no organization is set as the Primary Account, nothing is inferred. ### Nonprofit Cloud Limits the Accelerator Cannot Remove These are Salesforce platform constraints on the Account Contact Relationship object. They shape how you work with relationships regardless of this accelerator. * **Only one relationship can exist per Account-and-Contact pair.** You cannot keep several relationships to record a history of one person at one organization — which is why Start and End Date describe the current relationship only, and why there is no record of previous primary organizations. * **The Account and the Contact cannot be changed after the relationship is created.** To correct either one, delete the relationship and create a new one. * **Account Contact Relationship does not support reporting.** You cannot even create a report type on it, so a report of "every person's primary organization" is not available from the relationship records. Report on the Account fields the accelerator maintains instead — that is much of the point of keeping them in sync. * **Field history tracking is not available** on the object. * **The object has limited setup options** — no record types, Lightning record pages, search layouts, or conditional field formatting. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.