I make no secret that I’m a fan of PersonAccounts. I think they’re very handy when working with individuals instead of companies, and I really like pairing them with the Relationship Groups app to make households.
I’ve always considered them as mostly-contacts. I put all Person fields on the Contact object, reserving very few for the Account object. But for some reason, I’ve usually used Billing Address as the primary address and Mailing as the secondary. No reason – that’s just how I’ve done it.
That all changed yesterday. I was prepping to demo a system to a company and decided to click the “Request Update” button to send a Stay-In-Touch email. This is not a customizable email (well, not much) in terms of the fields from the Contact that it displays, so it used the Mailing Address. Oops!
From now on, I am using Mailing and Other addresses for PersonAccounts. Billing, you’re reserved for BusinessAccounts.
Feel free to debate the merits and drawbacks of PersonAccounts below – I’ll respond to them in a future post.
RSS Feed
Ah, PersonAccounts, the Siamese twin, idiot-savant of objects. Along with Black Tab features, I keep hoping a blogger will post a definitive list of benefits and gotchas since they’re not well-documented anywhere.
I’m very intrigued by your method of putting most fields on the Contact, we’ve inclined the other way but I’ll be re-evaluating to see whether that is justified.
The gotcha I’ll contribute is: Workflow Email Alerts. These do not recognize the PersonEmail field on Accounts. We’ve had to run an extra workflow rule to populate a custom Email field that is accessible by Workflow Email.
Here’s a gotcha I discovered:
I have a client who has a few of the Organization Accounts and alot of Person accounts. When they create an Opportunity on an Organization Account, they cannot add Contacts via the Contact role function.