The Salesforce Custom Person Object and Nonprofits

Salesforce is an incredible platform. The number of different things you can do out of the box, or even with just a handful of clicks, no code, can be found nowhere else in the software world. And yet, for as long as I can remember, there’s been an open question on the platform: What is the best way to track people as a <insert your organizations mission here>? We have Contacts. We have Leads. Users. Person Accounts, and now (drumroll please…) the Custom Person Object. All of these are potential options for your organization when thinking about how you want to model your data in Salesforce, and in particular, how to model your ‘people’ (the heart of your organization), in Salesforce.

As you might have heard, custom person objects are a pilot program offered by Salesforce starting with the Winter’15 Release that is designed to help address some of the challenges organizations may have had in the past with modeling the idea of an ‘individual’ and their interaction with that person. We have gotten more than a few questions about this new model and how it might benefit nonprofit or higher education organizations using Salesforce. While every organization is unique, for the vast majority of organizations out there, the Foundation today is still recommending utilizing the standard Contact and Account setup as the best path forward for most Salesforce deployments. Lets dive in and discuss!

Before we get started… what’s a “data model”?

Underlying all of the beautiful tabs, related lists, page layouts, Visualforce, etc. that is the Salesforce platform, there’s a big multitenant relational database (more information on the infrastructure is available here and on developer.force.com).  I’ll let you read up on the “multitenant” part on your own, lets focus on the “relational database” part here.  Like any relational database, various tables are linked together using keys to maintain the links between the data.  An overview of relational databases is a bit beyond the scope of this post, but you can find tons of great information on the internet providing an introduction on understanding the venerable RDBMS (relational database management system – we love our acronyms, right?).

Setting aside the technical details, what we’re really trying to get at is: how is your data structured? Are addresses on the same record as your people, or are they their own separate record? What about a Household, how do you put multiple people under the same (virtual) roof? How do you connect two people together, what information should you be storing about that relationship? All of these are a mere glimpse of the key components of how you structure or model information in your Salesforce instance. Fortunately, Salesforce does much of this thinking and application of best practices in the database world for you.

Why does a “data model” matter?

The data model defines how information in your system is connected together, and it also determine the behaviors and accessibility of that information for things like reporting, your user permissions and more.  Salesforce has an out-of-the-box model that’s ready to go for you. It includes the standard objects you’re likely already familiar with, things like Contacts, Leads, Accounts, Opportunities and more.

Of course, sometimes, the standard objects we know and love from Salesforce aren’t enough, and we need to include custom objects of our own design.  We can connect our custom objects to Salesforce standard objects, and design our own model that’s best suited to our organization.

However, the decisions we make with our data model can have consequences.  For example, imagine a fictional “Stay in Touch” app from the Appexchange that allows you to create new Salesforce Activities and Tasks in your database automatically.  If you designed a custom “Kevin’s Activities” object and made use of that instead of the standard Salesforce Tasks, the “Stay in Touch” app may not work for you since it assumes you’re using Salesforce Tasks.  That’s why most consultants, developers and administrators first start with the question:  “Can we just use a standard Salesforce object or function to accomplish what we need to?” before going the custom object or code route.

This same principle applies to modeling individuals.  Salesforce gives you some great tools out of the box, and most organizations will want to utilize what Salesforce offers in standard objects.

Custom Person Objects (CPOs)

Finally we reach our raison d’etre for this post.  Custom person objects are a new pilot program being offered by Salesforce that’s designed to help address some of the challenges of modeling the idea of an ‘individual’ and interactions with that person.  You can find out more about the pilot in this Ideas thread and also in the Spring 15 release notes.

So what is a Custom Person Object (CPO)? Its actually very similar to a regular custom objects, with a few important and powerful differences:

• Standard ‘person’-related fields are included.  Things like first name, last name, address fields, email, title, phone, etc.
• You can treat a Custom Person like a regular Lead or Contact in Salesforce, meaning you can send them emails, associate tasks and events, etc.
• Like custom objects, you can add custom fields, apply sharing rules or access the object in Visualforce or Apex

In many ways, a CPO is the best of both worlds in your data modeling exercise. It takes most of what you need from Contact and Lead, but gives you the freedom to customize the experience beyond the constraints of the standard objects.

What does the Foundation recommend for my organization?

Every organization is unique. However, for the vast majority of organizations out there, utilizing the standard Salesforce Contact and Account setup will be the best path forward for their own deployment. This is for several reasons:

1. Many organizations will not have the in-house expertise or know-how to customize their own data model from scratch
2. Salesforce.org products such as NGO Connect, Advancement Connect and the Nonprofit Starter Pack all rely on the basic Contact-Account model that comes ‘out-of-the-box’ for Salesforce
3. The vast majority of nonprofit and HED Foundation customers utilize the Account-Contact model, providing a robust community of expertise for new organizations to plug into
4. The custom person object feature is still in pilot with no committed date for general availability. If you’re looking to go live with a solution in the next few quarters, you’ll want to stick with what’s generally available

For organizations with unique customized applications that do not have need for tracking donors, volunteers, members or constituents, the custom person object can offer a great tool in your architecture and design toolbox. As always, we recommend talking with your local Salesforce partner or professional before proceeding down that path. And of course, you can always inquire in the Power of Us Hub (the Foundation’s online community).

The Foundation has, and will continue to work closely with the Custom Person Object team at Salesforce R&D to help provide input and also learn from their work, but as of today with the CPO program in pilot and not generally available, the Foundation products team does not intend to support it as the primary model within our applications.

Where do I find out more about data model options, with pro/cons?

There’s quite a bit of information out there on data models already available. In the Higher Ed and nonprofit space, we recommend starting with the Knowledge Base and Chatter group in the Power of Us Hub. If you’re a current user of Salesforce, you already have access to this huge community of users, administrators and partners in the space.

If you have specific questions about the custom person object itself, or the pilot program, you can reach out on the Salesforce Success community in the Official: People Chatter group.

Good luck, and happy building!