Sep 16th, 2021
Posted on Oct 21, 2020 Tools & Tips
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.
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.
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.
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?
Will the values contain a lot of characters?
Will they need to be updated through automation?
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.
Author: Grant Ongstad, Salesforce Consultant
I have worked on many projects with EightCloud and every time it is well organized, executed to meet my needs, and is completed professionally. EightCloud is a great partner to work with!"
- Kent Bigham, Harmar
Partners and friends, we are proud to share the new EightCloud brand and website with you. Our transformation reflects our commitment to helping you achieve Salesforce excellence through a focus on efficiency, expertise and genuine partnership.
We wish you the best and look forward to connecting with you soon!