Implementing Person Account

I have been lucky enough to be invited to present at the first London’s Calling (Europe’s largest community-led event for Salesforce professionals) on February the 5th, 2016.
London's Calling 2016
I chose a topic which meant a lot to me because I’ve done quite a lot of B2C implementations: Salesforce Person Account. Unfortunately, the presentation didn’t exactly go to plan as my PC crashed when I plugged in the projector. As a result, I didn’t cover the whole talk. So, if you were in the audience and felt left out or if you didn’t manage to join us on the day, this post is for you!

You can refer to the supporting slides that I’m sharing below.

Person Account issue

Person Account, or PA, in short, is the way to configure Salesforce to make it work for B2C users. It’s safe to say that PA doesn’t get much love in the community. Many consultants and administrators are full of bad stories explaining why you shouldn’t use it! That’s a bold statement considering that PA is a standard feature of Salesforce. While I was preparing for my talk, I searched for complaints on blogs and forums with the intention to propose workarounds for each of them. Well, I’m pleased to report that I haven’t found many road blocks that are still valid today. Most of the issues discussed online have now been fixed or are on the roadmap.

Here is the learning:

Old posts are not updated, and issues from the past can be fixed today. Don't believe old blogs post and always test for yourself.

It doesn’t mean that Person Account doesn’t come with annoyances and complexities. I can even see one particular issue which can become a show-stopper at times but as a Salesforce administrator, architect, consultant you shouldn’t base your design choices on rumours, especially for such a critical part of CRM systems as the customer data model. Please, think twice before discarding PA as the way to model consumers.

So, for instance, one of these rumours is that PA doesn’t support cross-objects formulas. It may have been true several years ago but I can tell you that this is now fully supported…

In fact, I believe that Person Account real issue is that Salesforce ships new features as early as possible without waiting until they support both Business AND Person Account. It’s a shame as it makes PA look like a second-class citizen whereas it’s in fact a very clever part of Salesforce (see slides 6 to 8 below on backward compatibility).

PA's often late...

So, in the end, it’s a waiting game. Some features are released without Person Account support and we know that at one point they will be improved for PA. It can be frustrating but this also applies to any software: you must design with what’s available at one time.

Mind the fake problems

One recent example of delayed delivery is Lightning Experience. In Winter ’16 you cannot have both PA and LEX enabled on the same org at the same time. Spring ’16 will fix this albeit with quite a few caveats in the way PA is supported and the following release will improve PA support on LEX. At the end of the day, Lightning Experience is not that critical to any implementation. Is it me or we’ve been designing quite a few powerful solutions in Salesforce Classic up until now? So, I guess we can wait for a few releases before making the most of Lightning.

Duplicate Management in another capability which doesn’t still support PA. Good news is that there are some (free) AppExchange to fill the gap. The thing is that deduping in a B2C multi-channels world to get a single view of consumers can be quite a difficult exercise depending on how you define duplicates: do you want to match consumers reaching you via phone call with their online identity on social networks? This can be a complicated requirement needing more than what the standard feature would deliver.

The downside of Person Account

Still, there are some problems with Person Account...

The main one, in my opinion, is linked to its architecture (1 pair of Account + Contact record per consumer). Using PA means that you are doubling the data storage required to manage your customers. If your customer base is in the millions, then this can get you to hit the storage limit and is the show-stopper I was referring to earlier. Good news is, this double count is on the roadmap to be removed! The data structure will remain the same, but Salesforce will only charge for 1 record (2 KB) “WHEN IsPersonAccount = TRUE”.

Person Account alternatives

There are options on the table to avoid the use of Person Account. Again, I would recommend to stick to the standard and preserve the capability to extend the first version of your solution in the future. But, if after carefully considering your design criteria, you come to the conclusion that PA is not for you then you could use one of my preferred alternatives:

  • Bucket Model: slide 20 below
  • Household Model: slide 21 below
  • Custom Object: slide 23 below

In the pipe

Salesforce is always improving PA and here is what they have in mind. Please do not make any purchase decision based on the list below (“safe harbor”):

  • Full Lightning Experience Support
  • Eliminate Double Storage Count
  • Admin Enable/Disable PA
  • Duplicate Management
  • Insight for PA
  • New Data Import Wizard
  • PA as Shared Contacts

The presentation I’m sharing above includes quite a few links that I suggest you follow to get a deeper insight into Person Account.

Sitting Duck

So, to summarise, I think that Person Account is a sitting duck which doesn’t deserve all the complaints I hear here and there. It has evolved quite a lot since Winter ’07 and, hopefully, you’re now willing to give it a second chance.

I hope you enjoyed this post. Don't hesitate to ping me on Twitter if you have any comment or question.

Fab 🐸