Contact Record Types vs. Custom Objects – Which to Choose When Serving Different Populations in Human Services

In considering how to distinguish (in Salesforce) between types of clients participating in different areas in the organization, it is essential first to determine the degree of separation between the different areas or programs. On the one hand, many organizations serve a specific population and offer multiple “programs” to meet that population’s varied needs. On the other hand, an organization might serve a few separate and distinct populations, and the departments serving those populations might also be more separate and distinct.

Three possible, not necessarily mutually exclusive, directions arise from this:

1. The Program Enrollment Model – we could consider all persons in our system to be “Contacts”, and their participation in different areas of the organization could be assigned to their Contact records as “program enrollments”. This is beneficial if we are confident a Contact might be participating in more than one area of the organization, especially at the same time.
2. The Contact Record Type Model – if we do not anticipate any overlap between organizational areas, we might consider using record types or custom objects. In this scenario, all persons would still be “Contacts”, but we would have the added benefit of being able to distinguish between different types of clients, providing different page layouts and picklist values.
3. The Custom Object Model – if our different types of clients are radically different and staff never work with or need access to information on clients being served in different areas, then custom objects might be the way to go. The rest of this post will discuss some considerations when choosing between Contact record types and custom objects.

This post will compare the latter two directions, assuming a scenario in which there is a high degree of separation between populations and very little cross-participation in different programs.

What Both Will Accomplish

Both Contact record types and custom objects will allow us to control the Page Layout, Compact Page Layout, and Picklist values. Furthermore, using record types does not damper our reporting abilities since we can filter by record type in reports.

Grouping in Household Accounts

A benefit to using Contact record types is that, since our records are still Contacts, we can still leverage the Household Account model in Non-Profit Start Pack (NPSP). Granted, we could configure a way to relate our custom object to Account, but that might not be as clean of a solution. For example, we would end up with separate related lists on the Account page for the different custom objects related to the Account. We would have a related list for Contacts, for Students, for Parents, etc. instead of all of them being listed in one related list on the Account record page.

Number of Custom Fields Needed

If the different types of clients will need a large number of unique custom fields, therefore adding several custom fields to the Contact object, then the Contact object might become challenging to manage.

Permissions & Security

Controlling access to the different types of client records is perhaps a little easier when working with separate custom objects instead of record types. Namely, we can omit object permissions from the profiles assigned to users in other departments/programs.

If a record type is not assigned to a user’s profile, this does not mean they cannot see records of that record type; instead, it only means the user cannot use the record type when creating or editing records. To prevent users from seeing records of a particular record type, we would need to set the Organization-Wide Default (OWD) Sharing model for Contact to “Private”. Then visibility would be provided to the appropriate users via Contact sharing rules (remember, Permission Sets do not control record-level access).

List Views & Navigation

If using Contact record types, by default, you will find records (no matter their record type) by navigating to the “Contacts” tab. Granted, a list view can be created to filter by record type, but a more descriptive label for the navigation tab might be preferable. If we use a custom object instead, we would have a separate default tab with a descriptive label (e.g., Students). However, when using record types, this limitation could be overcome by creating a new Lightning App Page for managing records of a specific type.

The Verdict

All in all, Contact record types are more than sufficient for making a sharp distinction between different populations of clients. Overall, there is no convincing reason to choose to create an entirely new custom object in which to store client records of a different kind.

But what’s your take on it? Anything I missed? Please leave your comments below…

Follow along in your inbox!

Advertisement