Using IsPersonAccount Field in Account Triggers

Great news! It looks like the IsPersonAccount field is always available for use in Apex triggers, without the need to retrieve the field values using SOQL!

The following test was used to reach this conclusion (in Winter '12):

1. Create a trigger that activates or fires before/after insert, before/after update and before/after delete.
2. Add code to the trigger to check every record in Trigger.new and in Trigger.old with the following assertion: System.assert(accountInTrigger.get('ispersonaccount') != null);
3. Create a test method to insert, update and then delete an Account.
4. Verify that the test passes.

Optionally, one can also use the following code in the trigger to take a deeper look at the basic information that's always available, depending on what caused the trigger to fire:

System.debug('Trigger.new = ' + Trigger.new);
System.debug('Trigger.old = ' + Trigger.old);

Mixing Person Accounts, Contacts and Business Accounts

I really enjoy the excitement of learning new things, especially through active discussion and target questions and answers. One of the subjects that never lets me down in this area is the concept of person accounts in Salesforce.

Having raved about it in previous posts, I feel obliged to answer a question that was posed about how to actually use person accounts and business accounts in the same org.

The answer could be fairly straightforward: In the standard sales processes, there's no need to mentally make a big distinction between the two. Opportunities are tied to accounts, not to contacts. This means that if a salesperson is trying to close a deal, it doesn't matter if the deal is for a person or for another organization. The opportunity is what's important, and it's always related back to the account entity, person or organization, with which you're doing business.

A trickier question which we're running into at work is: What's the best way to handle people who are both your direct customers and who are contacts at other organizations? Theoretically, the idea of linking the contact to both the business account and to the person account would work. In practice, however, I think if an organization is investing time and energy into this level of constituent mapping, then it would be worthwhile to analyze the business needs and maybe setup some workflow, Apex and Visualforce to take advantage of the data links.

Not to dodge the question entirely, but I think that there are always specific organizational needs that drive people to setup more complex and complete data models. If anyone's interested in discussing a specific use case, I'd be totally game!

The Ingenuity of Person Accounts

As I meditated more on the idea in my previous post about people's connections to different accounts, a surprising realization occurred to me: We don't even have to engineer a new object; Salesforce has already done this for us! And the answer is... Person Accounts!

The basic implementation can be done in two simple steps:

1. Activate the Person Accounts feature.
2. Create Person_Account__c as a Lookup(Account) field on the Contact object

Conceptually, the idea is simple: The person is the core piece of the puzzle. Take John Doe, for example. John can be a contact for Acme Corporation and simultaneously be a contact for Zenith, Inc. All that's needed to represent these relationships are a person account record for John, two business account records for Acme and Zenith, and two contact records to link John to the two accounts.

Although I haven't thought this next idea in much more depth, I have an inkling that this model could potentially even replace the Nonprofit Starter Pack's Household object with a "Household Account" record type. Wouldn't that be a beautiful alignment of developer resources? All of Salesforce's main development efforts on Contacts and Accounts could then directly benefit all users in every industry. No more waiting for updates to the NPSP Householding package; just wait for the next seasonal release of Salesforce.

keeping Person Accounts on the roadmap

From a discussion on Person Accounts yesterday, a Salesforce Foundation representative said about Person Accounts, "we do not have a roadmap going forward but the current offering is going to continue". What does this mean to us as Salesforce customers and prospective customers? One school of thought says that having no roadmap indicates that the feature is on its way out. Another school of thought says that having no roadmap simply means that at the current time, the feature meets most if not all of users' needs and has no need to be on a roadmap.

But let's stop for a second and think, "Why is this feature important?" My thought on that is, "Should a database be structured to match the business model?" To me, the entities with which we do business dictate whether we should use Person Accounts or not. If we contract and transact with other businesses, then accounts with contacts would work. If we contract and transact with individual people, don't person accounts make more sense? A simple use case is managing individual donors and contributors for nonprofits. Another use case is managing students at an institution of learning.

But perhaps most importantly, what are some of the pros and cons of using Person Accounts? I'll admit that I'm probably biased because we use Person Accounts in two of our orgs, but I hope not to lie when I say that I would love to know all of the benefits and liabilities of using this feature.

Below are starters taken from an editable document shared with the public, in lieu of something more authoritative from Salesforce.

Some pros:

• The model fits the B2C way of doing business.
• You can contract with people instead of businesses using the standard Contract object.
• Person accounts will show up on both account and contact reports, which would be accurate for a company that mixes B2B with B2C.
• Person accounts can leverage both Account fields and Contact fields via a single sObject.
• Contact fields are directly accessible for a Person Account via Apex through a single Account instance.

Some cons:

• To convert a lead into an opportunity for a new person account, the lead cannot have a value in the standard Company field.
• For person accounts, formula fields at the account level cannot reference contact fields.
• Code may have to account for the fact that there are now two record types on the Account object.

Personally, I believe that Person Accounts make a great selling point and feature for the Salesforce products. If being off the roadmap is a fault, then maybe we just need to promote some of the ideas on the IdeaExchange that will make the feature even stronger and more compelling:

• Create a person account from outllook
• Reference Person Account Fields in Formulas