It was the last day of Dreamforce ’13. Francis Pindar (@radnip) and I had just finished up manning the Genius Bar that morning, and box lunches in hand, we trekked the 10 blocks from the Hilton Grand Ballroom over to the Yerba Buena Center for the Arts where Parker Harris’s True to the Core session was in progress (a very popular session with the Salesforce Community). Shawna Wolverton was just finishing a presentation and Q&A was starting.
One of the first questions that came up in Q&A was about some challenges with the non-profit starter pack which spawned an interesting side discussion. Steve Tamm, CTO, jumped into the conversation and mentioned the concept of “People” records. Now why did I think this topic was particularly interesting? It alluded to a potentially fresh look at how people exist in Salesforce.
Today in Salesforce the concept of people are isolated to two objects – Leads and Contacts. For those of us that grew up with Salesforce over the last 10 years or so, it makes sense. For those businesses that don’t have the concept of Leads, or for organizations or users coming from other databases where a Contact can exists in multiple tables, there can be a lot of confusion. So much so, that I dedicated a ShellBlack Whiteboard video blog post on the subject of understanding the concept of Leads and Contacts and how they differ in the database.
People come in many flavors, shapes and sizes
In Salesforce you can have all sorts of Contacts – people who work at a company, your prospects, your customers, and internal Users. When you go down a level and look at the concept of people by industry the relationships get more complex. How do you treat insurance policy holders or beneficiaries, doctors and patients, donors and volunteers, referrers or brokers?
Traditionally when someone said “person” the best practice was always to make a Lead or Contact to ensure down the road you didn’t miss out on native functionality. If you needed to relate two Contacts together you could use a lookup field or a custom object to create a join relationship in the database. Depending on the complexity of your business, tracking and reporting against all the one-to-many and many-to-many relationships gets complicated. It can also make the Contact page, with the extra Related Lists to track the relationships between Contacts, very busy. Admins have to leverage record types and unique page layouts to help Users make sense of the relationships (e.g. this is the “Broker” Contact page layout vs. the “Client” page layout). When a person can only be a Contact record, there can be a lot of work keeping the relationships straight and logical to your end users.
Should every person be a Contact?
There are instances where you need to capture the name of the person but you feel like that individual doesn’t deserve being a full-fledged Contact. For example, let’s say you have a donor giving a contribution in the name of someone (e.g. “in memory of”). You probably want the donor to be a full Contact (with email, phone etc.), but the person being named in the donation probably should not be a full Contact. In this use case, you only have a name of the person and no other contact information so it would be a relatively weak low-value record (not to mention you avoided creating another record in the database).
Penalties for creating custom Contact records
Not too long ago I saw a radical implementation of Salesforce that was deployed by a perspective client where they had abandoned the Account and Contact data model and essentially recreated Contacts as a Custom Object. They literally divorced themselves from the core CRM functionality and did the whole implementation with Custom Objects and custom code. I suspect they were looking for a less expensive licensing model (using Force.com licenses), but going “rogue” carries a penalty in other areas. When you use a Custom Object as a place to store a “person,” you abandon a lot of native functionality such as email, campaigns, web-to-case and web-to-lead, event invitations, email sync, as well as a slew of third party AppExchange solutions.
Another issue when re-creating the concept of a Contact using a Custom Object is when you take your data model public with a community (or portal). A lot of the security and access built into Salesforce assumes you are using Contacts. Your Contacts become your portal users!
Imagine the possibilities with People
For Salesforce.com to pull off a “People” data model would be a massive fresh look at the data model impacting security and access, marketing functions, communities (portals), and customer support functions. It could potentially address some of the obstacles that Admins face today with Leads: the inability to customize the conversion process, the issue of creating Custom Objects on Leads (which get dropped during the conversion process without custom code), the difficulty in relating Leads together in relationships, as well as managing duplicate records that exist between Leads and Contacts. Can you imagine a Lead just being a status of a Person record rather than existing as a separate record in the Lead object?
What else could be accomplished with a “People” data model? How about allowing a Custom Objects to have the same functionality as a Contact? For example allowing records in that Custom Object to be users in a community, able to be sent mass emails, participate in Campaigns, open a Case, or even be Users (by assigning that person record a User license)?
UPDATE (Sept 2014) – In the Winter ’15 release there is now a pilot program for a “Custom Person Object”
This is all speculation – yes this was a Safe Harbor conversation at Dreamforce – but I thought it was a very intriguing topic: People are People in Salesforce! Sorry, I couldn’t resist the Depeche Mode reference…