3 Tips for Building a Salesforce Data Model That Scales.

If designing a Salesforce Implementation is like building a house, then the Data Model would be the foundation. And the frame. And the tile work.

Okay, it’s not a perfect analogy, but it’s safe to say that post-implementation changes to the data model lead to some of the more costly repairs and renovations.

The following guidelines will help you nail down your data model during implementation to support future growth while avoiding rework.

1. Use Standard Objects

Salesforce Standard Objects are designed to meet many business cases. No matter how unique your design needs seem, start with Standard Objects. Salesforce puts their efforts, market research and development into the Objects they support. When you use Standard Objects, you’re following best practices – making it easier to implement and maintain your implementation.

For instance, instead of building two Custom Objects to track mechanics and electricians, try using Person Accounts and splitting them by Record Types. Thinking about building a new Custom Object to track internal equipment failure? Try exploring the Case Object. For more reasons to stick with Standard Objects, check out this great Salesforce Blog.

2. Avoid Repeating Groups

One tenet of relational databases is normalization – the act of removing redundancies. Normalization increases the performance of database actions, saves space, and leads to a more structured database design. Here’s a common example of where an Object should be further normalized.

Let’s assume that we store information about Contacts and track their attendance to one of our annual conferences. On the Contact Object we have created a new checkbox field for each year: 2017 Attendance, 2018 Attendance, 2019 Attendance, 2020 Attendance.

This is a violation of normalization because we are storing repetitive attendance information by repeating the same attribute (whether they attended a particular year). Assuming this is the way attendance continues to be tracked, how will it look after 10 years and 10 more fields? I’m sure you’d agree that it would be a mess.

What if we wanted to track additional attributes related to attendance, like whether they attended our VIP seminar? If we follow this design, we’d have to add another field for each year. Reporting would be a nightmare.

We can normalize this design by off-boarding the attendance fields to a new Custom Object. Instead of creating a field for each year, we can create one field for year and one for their VIP Seminar Attendance and create a new record to indicate conference attendance.

This simplifies reporting and makes it easier to scale in the event of an increased need to track attendance related information.

3. Think before you multi-select

I’m not going to say never use a multi-select picklist. Just think really hard before you do so. A multi-select picklist technically disobeys a rule of normalization by storing multiple values in a single field. It’s almost never the way to go.

If you’re considering using a Multi-select picklist field, ask yourself the following:

Will I need to report on this field?

• Example: getting a unique count of an occurrence of a specific value.

Will the values contain a lot of characters?

• Longer values are truncated.

Will they need to be updated through automation?

• Since Multi-select picklists are stored as a semi-colon delimited string, you’ll have to do a lot of extra work to add or remove values.

One benefit of multi-select picklists is that they are easy to use. So, consider whether the trade-offs are worth it before using. Normalization may add a few more steps to the user experience but it’s much easier to make changes later to the way data is entered than the way it’s stored. Try using Visual Flows to streamline the user experience.

Starting with a great data model design will increase performance, save development time, and help your implementation scale for future changes.

If you’ve found this blog helpful, check out our free DIY Implementation Guide.

DOWNLOAD NOW

Author: Grant Ongstad, Salesforce Consultant