As evidenced by its predominance across nearly every industry able to leverage CRM or automation tools, the greatest value proposition Salesforce has to offer is the ability to customize a tailored solution to fit the unique needs of your business. The need-specific product offerings, like Marketing Cloud or Service Cloud, provide additional tools on which to build, but the inherent promise of customizability permeates through them all. And though the users benefit from all the features packed into this tidy package, the sheer amount ways you can customize to address a particular need can cause fear, uncertainty, and doubt (FUD).
Whether you are new to Salesforce
or have been using the platform for years, it can sometimes be difficult to
know when to utilize its native form and function versus building a custom
solution to best fit your needs. One of the simplest (yet still complex) examples of
this is the use of custom objects.
Imagine you have just signed into your new Salesforce org for your sales-based business, and you are ready to start building out the platform. You have a checklist of tasks for new accounts that you have been keeping in Excel and want to bring into Salesforce. The tasks could be automatically created as task records for each new account, but your process doesn’t exactly match the native function of task records. Additionally, you have over 100 tasks per account, and you don’t really like the idea of having that many related tasks to keep track of.
You start to think about maybe creating a custom object that houses the task list and keeps track of their status. Then the dilemma sets in. If you use a custom object, are you going against the intended functionality of the system? Would you be missing out on key features that are linked to the standard object?
This is the kind of scenario Salesforce admins face constantly, and the concern is valid.
It does not, however, mean we must remain in FUD about the value of custom objects. By understanding our business processes and breaking down the requirements into digestible and translatable objectives, we can be confident that the solutions we build will meet our needs. And properly deployed custom objects play a crucial role in delivering on that inherent promise of customizability.
What is a Custom Object?
To answer the question, “What is a custom object?” it would first help to know what objects are at all.
In Salesforce terms, objects are database tables where business-specific data is stored. Think of it like a spreadsheet where columns represent different fields and rows represent different records. When you need to represent a relationship to another object (ex. a Contact to an Account), one of those fields will hold that relationship.
Depending on the Salesforce product you are using, a variety of these objects and relationships will come standard on the system. These are called standard objects and some of them are important for system functionality, like the User or Profile objects. But many more of them are intended to represent common business objects like accounts, contacts, leads, etc.
As you may have surmised by now, custom objects are objects that are not standard. These objects can be created by the user or may come as part of a package installed from the AppExchange or somewhere else. And their purpose is to provide a method for users to store data and relationships in ways that would not be fully serviced by a standard object.
Simply put, if you
have data that you want to store in Salesforce, but it doesn’t make sense to use a
standard object, you could create a custom object. You may be wondering, “This
sounds simple; why would anyone be afraid of custom objects?” There are a few
very important components to that answer.
Custom Object Considerations
What Could Go Wrong
1. Relationships, Redundancy, Reports
These 3 R’s represent the structural aspect to consider when
determining how objects fit in the data model. It’s all fine and good to have a
custom object sitting alone by itself with no relationships to other objects, but the value of this is limited. Relationships add dimensions to your data and
allow you to draw deeper insights and find meaningful patterns that you can act
on. That is if the relationship is represented accurately.
As an example, consider a business that utilizes the
standard Account and Contact objects but has another type of contact that they
want to segment from their standard contacts because they serve a different
role on the account. To facilitate this, their admin essentially clones the
Contact object and calls the new custom object Contact 2. And some of the
standard contacts may also be Contact 2’s, so they will have records in each object.
After a while, the admin notices some flaws with the option
they chose. Because there are redundant records between objects, some
discrepancies in contact data exist due to users not updating both records, and
they don’t know which contact information is correct. Also, they now have to run 2
separate reports to see all their contacts and have to manually stitch them
together to get the actual report they need. On top of that, there are even more issues to deal with.
2. Record Sharing
After creating the Contact 2 object, users started noticing
that almost everyone had access to all the new Contact 2 records. The standard
Contact object had sharing settings established that represented record access
by sales division and territory. But the new custom object was created with
public read/write access and users who should not have had access to certain
records had erroneously modified them.
3. Object Permissions
Additionally, issues with object permissions for the Contact
2 object were not correctly established, causing users not to have visibility of certain fields that they should have, or not able to see any records at all.
4. Features and Automation
Lastly, users reported that features and automated processes
built around the standard Contact object could not be readily utilized with the
new custom object. They learned that leads may only be converted to a standard
Contact record and that a record-triggered flow to send notifications and make
field updates would need to be cloned and amended to facilitate the new object.
Clearly, the admin in this example did not fully realize the
consequences of this approach. Had they done so, they may have looked for
alternative solutions that leveraged the standard functionality of Contact
Roles, bypassing the need for a custom object. This cautionary tale only serves
to illustrate the value of a thorough comprehension of your business processes
related to your requirement.
Now let’s explore an example where analysis and
proper utilization of Salesforce tools produce a satisfactory solution.
What Could Go Right
Company A is a service business that provides inventory
management to its accounts. These accounts should be able to see and place
orders for inventory held by other accounts that they have an agreement with.
Because these relationships changed so frequently, they could not use Groups
alone to share required records. Their admin realizes that to be able to meet
this need, a representation of a many-to-many relationship between account and
account will need to be used.
The admin evaluates their options and determines
that the relationship itself should be a record and that no standard object
would be able to be utilized to meet this need. They create the custom object
(aka Junction object) and use this as a foundation to build
their entire management solution.
Because the relationship between accounts was accurately
understood, a mindful evaluation of their needs resulted in a new object with
no redundancies. Additionally, because the custom object was used to relate
inventory and order data between accounts, they were able to create reports
that contained all the information they needed without extra manipulation.
As a
part of deploying their solution, Company A’s admin based their sharing rules
on the junction object to ensure each account had access to the records they
needed. Finally, because this custom object was a completely novel
representation of data in their system, they did not need to worry about
granting object permissions to their external users or maintaining access to
flows or standard features.
Though the extra analysis of their requirements
cost them some time in the beginning, the value realized through the end
product was far greater than if they had mimicked the route taken in the
previous example.
When to Use a Custom Object vs. a Standard Object
Now that you have seen examples of both a poorly conceived
utilization of custom objects and a skillful one, it may still be tricky to
discern when the proper situation is to utilize them over a standard object.
There are also some less obvious factors that you should consider depending on
your situation. To distill the lessons we learned earlier and add some
additional context, here are some questions you can use to help guide your
decision.
1. Is there a
standard object that mostly represents the type of data I am looking to store?
Often, if there is a standard object that exists which could serve as the
target object with some mismatches (ex. Missing fields, relationships, or
segmentation) you may want to consider some ways in which you could use the
standard object and make modifications. A combination of fields, record types,
page layouts, sharing settings, and other features can go a long way in meeting
your needs.
2. Are there
features specific to a standard object that cannot be easily replicated with a
custom object?
In addition to the lead conversion example in the scenario
above, certain features and rules may be specifically scoped to standard
objects. Consider the requirements of your needs and if they intersect to help
you decide.
3. Are there
fields on a prospective standard object that I don’t need?
Some standard
objects have required fields that may not be necessary for your needs. For
example, Opportunities require a close date for the record to be saved.
4. Are you
planning to utilize the same object for many different apps?
If many
divisions or people will be storing data in the same object and require
different record types, page layouts, and security settings, it may make more
sense to create a custom object. Depending on the nature of the object, the
needs of the business, and the effort of maintenance, a custom object might be
better suited to the job.
5. Will creating a
custom object require the creation of additional objects?
If you are
attempting to recreate a relationship between a parent and child object, you
very well may have to create more than one custom object. This may be easily
doable depending on the situation but could also cause an undue amount of extra
work.
Do Not Object to Custom
At this point in our understanding of custom objects, I sincerely hope you’ve been assuaged of any residual FUD. The fact is that if you intend to bring your entire business into the platform, it is unlikely that you can get away without needing to create a custom object at some point. But that should not be any reason to raise fear, uncertainty, or doubt about the way you use objects, so long as you employ thoughtful analysis to the particular needs of your process. Custom objects are meant to set your data free (figuratively), not pigeonhole it into some object that was never intended to hold it.
If you wish to explore the true potential of a thoughtfully designed data model in your Salesforce org, please to contact DB Services for any questions you may have!
