By default, accounts in Salesforce are designed for a business-to-business (B2B) model in which accounts represent firms and contacts represent individuals working at those firms.
Salesforce created the person accounts model for organizations that not only have B2B transactions but business-to-consumer (B2C) interactions as well.  

In a Salesforce Success Community Post Salesforce states “person accounts in Salesforce have a combination of fields from both accounts and contacts, and can be used as contacts in most situations that involve contacts.”

The person accounts model transparently combines Account and Contact objects and eliminates the workarounds that membership organizations have had to implement in the past.

Salesforce recommends using person accounts when individuals receive products and services.
A person account contains all standard account fields and all of the standard contact fields, with only a few exceptions.  

Person accounts co-exist alongside your conventional business accounts. This approach allows for interchangeable and transparent use between the two for your business transactions.

All Associations Deal with People (Even Trade Associations)

Professional Associations are made up primarily of individual members.  A trade association’s members are organizations, and at the same time most of their interactions are still with individuals.

The person account model was built by Salesforce to enable the business-to-consumer transactions for organizations whose customers are individuals.

Implementing person accounts is the recommended strategy to facilitate transactions with members who are individual human beings or people who represent organizations (in the case of trade associations), such as a dues payments, donations or event registrations.  This use case is exactly what Salesforce had in mind when they introduced the person account model in 2007.

Person Accounts Advantages for Associations

  • Standard Option – Person accounts is not a workaround or customization. It is a standard Salesforce feature that is tested, maintained, and supported like any other feature.
  • Level Playing Field – Search, Activities, Tasks, Invites, Events, Campaigns, Leads, Contact Roles, List views, and Reports all work with person accounts and offer a significantly better user experience than the messy alternatives.
  • AppExchange Support – The vast majority of AppExchange applications support person accounts out-of-the-box.  (List of some that our Nimble AMS customers use)
  • One Search Result - Person accounts show up once in search results.  The same person can show up twice using the alternative 1-to-1 approach.
  • Person Contact Lookup – Issues with cross-object formulas and other gaps can be circumvented with a simple custom field and trigger, and adds a lookup from the person account to the person contact.
  • Easier/Unified Reporting - Since both an account and contact record are available for each consumer, reporting behaves as expected. Since person accounts provide both an account and a contact, which are maintained in tandem, reporting works as expected, making it easier to see the big picture.
    There are strong differences between running a report for an account and running a report for a contact (they are two completely separate objects).  Since both accounts and contacts are expected to be used in tandem, often both records are needed to report on the big picture and the person accounts model makes that simple.
  • Visibility/ One Tab for Everything – Person accounts give the user a much easier paradigm for viewing records; both organizational and individual records appear in a single accounts tab.  With person accounts users have one central place to have complete visibility to ALL constituent records. This is significantly easier than of only looking at organizations in the account tab and only individuals in the contact tab.
  • Flexibility - Allows B2B and B2C simultaneously and seamlessly within the Sales cloud.
  • Consistency – All individuals (stand alone individuals as well as individuals affiliated with with an organization) are in person accounts.  Having a mixed deployment with some individuals as only contacts and others as person accounts would be challenging for the association staff as it would require them to manage individuals in both the Accounts and Contacts tabs and that would be confusing.  Centering all of the individuals in 1 method streamlines the process.

Improving Person Accounts

The NimbleUser team recommends two simple improvements during implementation for person account orgs to further improve the user experience:
Training on Nuances of Cross Object Formula Differences
Cross object formulas (i.e. where one formula incorporates data from both accounts and contacts) with person accounts have some nuances because some of the fields technically reside on the account object, and some of them reside on the contact object.  During implementation we highlight these differences to make formula creation smoother.

Trigger to Populate PersonContact Relationship
When working with person accounts there is a gap in the standard implementation.  Once person accounts are activated, the system automatically populates a PersonContactId field on every new person account. While the system provides an id, it does not provide a relationship.  For Nimble AMS customers we address this issue with a simple trigger that automatically populates the relationship.  (See the notes below from Nimble AMS Engineering to see the trigger code).

Are There Any Downsides to using Person Accounts?

As stated above there are overwhelming advantages for an Association or non-profit to use person accounts but it should be noted that there are some things that users should be aware of: 

  1. To enable person accounts you must contact salesforce.com.  It is not a configuration that your administrator can turn on.  If you are a Nimble AMS customer, this is handled by the implementation team during provisioning.
  2. Some of the apps on the Salesforce Appexchange do not support person accounts.  At NimbleUser we have found that the vast majority do support person accounts and virtually all of our customers have numerous applications installed in their instance (sampling of Appexchange apps used by our customers).
  3. From a developer’s perspective writing test classes for triggers is slightly more elaborate because of the way accounts and the contacts need to be linked when creating test cases.  Training on the nuances of this is given to our Nimble AMS customers that do their own development on the platform.
  4. Currently the change cannot be undone.  NimbleUser had a call with the Salesforce manager of accounts last week and she noted that (safe harbor applies) Salesforce is addressing this and in the future an organization will be able to undo this change.  As a note we have not had a single customer run into any issues or have desire to go back to the old way.

Alternatives to Using Person Accounts

There are a number of alternatives to using person accounts. The NimbleUser engineering team extensively researched each of these alternatives and prototyped each of them.  The team determined that person accounts was a much better solution for professional and trade associations.

There are two major alternatives to person accounts:
Nonprofit Starter Pack (NPSP) 1-to-1 ModelThe 1×1 strategy automatically creates an account for every contact (effectively creating a person account).  It represents an individual by maintaining a link between an Account and Contact for that person.  For Example for an individual Contact “Jane Doe” there would be a corresponding Account created via a trigger called “Jane Doe Account Record”

Issues with 1-to-1 Model

  • Requires two objects for storage (one Account and Contact per individual)
  • Searching returns two records for each contact.  For example searching for “Jane Doe” returns the contact and account records for Jane Doe.  If Jane Doe changes her last name, it needs to be updated on both the contact and the account
  • Different information on the contact and the account needs to be synced
  • Validation rules and required fields can restrict Account creation
  • It can be difficult to determine if an account is B2B or B2C because a B2B account with a single contact resembles a 1:1 B2C account
  • Merging Contact records with Salesforce.com’s standard Contact merge doesn’t currently work
  • Lead conversion works but does not allow you to merge to an existing Contact or create an Opportunity upon Lead conversion

NPSP Bucket ModelThe bucket strategy assigns all contacts without a company to a single account (or “bucket”).

What is the Bucket Model? Similar to the 1-to-1 model, this is a package maintained by the Salesforce Foundation that represents individuals by linking Contacts to Accounts. Where they differ is that the bucket model links many Contacts to a single Account whereas the 1-to-1 model maintains one Account per Contact. This model does conserve space, but impacts reporting capabilities.

Issues with Bucket Model 

  • All contacts to one account can be a difficult paradigm for many users from almost all contact aspects; adding, editing, finding, etc.
  • Reports need to be created differently for B2C vs. B2B Accounts
  • At large data volumes multiple buckets need to be created to support reporting (reporting breaks down after 10,000 entries are added to one bucket) and this may affect performance of reports, page loads, etc.

 Notes From Nimble AMS Engineering

For Nimble AMS, person accounts dramatically simplifies our data model so that both Professional and Trade Organizations implementations share the same code base. In one case, people join the association directly, in the other case, companies are the association members. Without person accounts, we’d be faced with redundant development and a lot of messy workarounds.

Before creating Nimble AMS, NimbleUser created a few Salesforce AMS implementations without person Accounts. However, associations cater to organizations as well as individuals and all of our clients then and since have that requirement. We used the Sales Cloud to manage orders by leveraging Opportunities, Leads, Accounts, and Contacts. However, since Opportunities can only be tied to Accounts and Contacts represent individuals, which may or may not be tied to an account, we had to come up with different models to support the various scenarios.

PersonContact Lookup Trigger
When working with person accounts, many organizations stumble over a strange gap in the standard implementation. Once person accounts are activated, the system automatically populates a PersonContactId field on every new Person account.

While the system provides an id, it does not provide a relationship. Administrators then run into places where a Person field needs to be referenced through a relationship with the account. For example, you might have a list view on a custom object, and you might want to bring in the City and State from the PersonMailingAddress. Out of the box, you can’t reference the Person fields based on a relationship to the account.

Happily, the missing PersonContact lookup is easy to implement as a simple trigger.

Every person account org should implement a PersonContact lookup trigger
Before implementing the trigger, add a “Person_Contact” lookup relationship on the Account that looks up to the contact. The trigger then uses the PersonContactId to populate the relationship. The id is null for business accounts, but, since a lookup is optional, that’s OK.

The PersonContact lookup neatly closes the feature gaps some folks find in the standard person account implementation. ​
trigger PersonContact on Account (after insert, after update) {
List<Account> personAccountsToUpdate = new List<Account>();
for (Account newAccount : newAccounts) {
// Person Account fields can’t be
// referenced directly in packages.
Id pcId = (Id) newAccount.get(‘PersonContactId’);
if (pcId != null && newAccount.Person_Contact__c == null) {
// Update only what needs to be updated.
// Including the entire new account record
// may have unintended consequences. Also,
// a select isn’t needed and wastes a query.
Account paToUpdate = new Account(
Id = newAccount.Id,
Person_Contact__c = pcId
if (personAccountsToUpdate.size() > 0) {
update personAccountsToUpdate;
view rawgistfile1.cls hosted with ❤ by GitHub
Affiliation Tree ViewNimble AMS has a very robust Affiliations structure to represent members.  This structure allows Nimble AMS to model our customer’s membership composition and provide a hierarchical view between a business and individuals as well other organizations affiliated with the parent business.​

One Affiliation custom object can define every account relationship

  • Business to Business
    • Gotham City Office affiliated with Wayne Enterprises
  • Individual to Individual
    • Jimmy Olsen affiliated with Lois Lane
  • Individual to business
    • Bruce Wayne affiliated with Wayne Enterprises
  • Allows for other affiliation types

Our Affiliations model supports the traditional 1 to 1 relationship seen in many trade associations (I.e. Jane Doe is affiliated with only one company). This approach is analogous to the traditional Salesforce model (Each Individual is related to one organization).

The Nimble AMS Affiliation model has the added flexibility of supporting 1 to many relationships.  This model really benefits medical, banking and other associations where one individual may be affiliated with more than one location, branch or other organization. In addition, the model supports history so the association can see affiliation history (I.e. Dr. Jane Doe was affiliated with General Hospital from 1981-2012 and with Northwest Hospital from 2013-Present).

Additional Person Account Resources


Person accounts are ideally suited to the needs of professional and trade associations as they facilitate the transactions and interactions that associations have with both organizations and individuals.  ​

NimbleUser & Nimble AMS ​

NimbleUser focuses on empowering professional and trade associations, whose members and staff strengthen the collective voice, leadership, and educational programs that drive change and improve our society.
NimbleUser has been helping associations and nonprofits become nimble through technology since 1992. Our flagship product, Nimble AMS, is an enterprise class Association Management System built on the Salesforce Platform, the world’s leading and most innovative customer relationship management (CRM) system.