PersonAccounts
Alright so PersonAccounts.
We've had issues with PersonAccounts at previous implementations. Some consultants lobbied to bring them back for B2C customers, feeling they deserved another chance.
That was a mistake. PersonAccounts are an ass, and we won't be working with them again.
All memes aside, here's a quick rundown of what PA is, when it's useful, and why most of the time it isn't.
WHAT ARE PA
To quote Salesforce "Person accounts store information about individual people by combining certain account and contact fields into a single record.".
Except that's wrong.
Technically speaking, Salesforce does not support a pure B2C model at all.
PersonAccounts were invented to fill that gap. Except how do you shoehorn B2C into what is an already sizable application at the time ?
- you could rewrite the entire thing to allow single contacts, which will also force you to rewrite your entire security model
- you could cheat and just merge two records together, call it a single record, and call it a day.
Option 2 is what Salesforce did.
So at the end of the day, a PersonAccount is just an Account and a Contact record, linked together via a couple lookup fields, that display as a single record in the UI.
This has a couple of interesting followups:
- PA have two IDs, one starting with 001 and one with 003
- PA take twice as much space as most SF records (so 4kb per record)
- PA can be used with most functions that are account or contact specific
- You can look from a record to a PA two times if you have an account and a contact lookup field
In general you can really just consider PA as the two individual records that comprise them, but masked to the user as a single one.
WHAT PA ARE SUPPOSEDLY USED FOR
PA are the answer to "I don't have accounts in my company" or "we're a B2C company". In theory at least.
PA work beautifully in small- to mid-size companies that have these considerations.
They're easy enough to set up, they answer that "no account" problem, and they're compatible with campaigns, hell they're even compatible with Marketing Cloud.
One thing that generally gets overlooked is that PA also lower the problem of having sharing settings for accounts, which is also great for those companies.
So if you have less than 500k customers, don't have tons of business-focused interactions, and want to do B2C, PA might be good for you.
WHY PA ARE ALMOST NEVER USED
The problem with the above are that PA are pretty much unfit for the purpose of B2C.
Before we get into bugs, let's look at that first paragraph again. It doubles your storage requirements. If you have 1 mil contacts, all of a sudden you're paying for 2 mil records in Salesforce. At big volumes, that is HUGE.
Then you have the sharing consideration.
"If you have enabled person accounts, the organization-wide default sharing must be set so that either Contact is Controlled by Parent or both Account and Contact are Private." That's a prerequisite, and you can't change it after activation.
So if you only have PA, you're fine.
But hell, if you have PA and normal accounts, you better hope you like sharing rules and apex sharing, because you're going to have a TON of it.
Let's add a sprinkle of dev in there.
Yes, PA are both Contact and Account. No, you can't use the Contact ExternalId fields to find them for some reason. Yes, querying the Account table will list PA. Yes, it will also show them in the Contact table. All of that is not blocking but it can make for hugely annoying situations.
Did I mention that Marketing Cloud supports PA but not great and that you'll almost certainly use Ampscript to compensate for it ?
And then there are the bugs. Process Builder doesn't ike PA at all. Hell even Workflows sometimes do weird shit if you're targeting email fields. APEX will have issues that devs are supposed to know as well.
It's just hell.
SO WHAT DO I DO WITH ACCOUNTS in B2C
Open your mind to the greatness of Cthulu.
Or otherwise, guide you clients to using accounts, not as companies, but as arbitrary groupings of contacts.
Hell a PA is just contact and Account anyway, so even if all contacts have a unique account, you're still at parity.
B2C commerce ? Use accounts as families! Base them on last name. Easy grouping of family members, nice reporting.
Insurance ? Do households ! Accounts are addresses with contacts in them You insure a place ! Yay !
None of that applies ? Why not use accounts as a billing entity ? Hell, whateer you do will be better than PA!
So TL;DR use them as arbitrary groupings of contacts that fit business needs.
Or, if you really, really fit the use case of small to mid-size company with no business processes that block PA and don't want to think too much about Architecture, use PA. And migrate away from them in a few years, because you're going to.
Love & Kisses!
Some Counterpoints and external links
https://www.quip.com/5XcaAbb43xWn/Person-Accounts-for-FSC-FAQs-Partners
https://developer.salesforce.com/docs/atlas.en-us.financial_services_cloud_admin_guide.meta/financial_services_cloud_admin_guide/fsc_admin_data_model_diagram.htm
1 Comment
Second link isn't set up as a hyperlink, for some reason. Otherwise great article with good points.