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!