Skip to main content

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.
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:
  • 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 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.
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.
  • Both NPC and Stakeholder Management have been installed and set up in your org
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.
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.
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 “<person>‘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.
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

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.
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.
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.
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.
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.