All businesses have customers, and almost every industry needs an all-in-one toolbox that can help manage customer information – from the database to automation and everything in between. Using this need as the main selling point, Salesforce has dominated the business scene by providing companies with the ability to customize almost everything in their org. Now, who wouldn’t want that kind of power?
Whether you’re a Salesforce newbie or a long-time expert, you know that there is a very wide (and consistently growing!) range of customizations that can be done to a Salesforce org. Over time, it can be difficult to identify what solution goes best with which specific need, so in this lesson, we will cover two of the basic ones: custom objects and record types.
What Are Custom Objects?
To understand custom objects better, it’s important to know what objects are in the first place.
Objects act as containers that house information within your Salesforce org. Think of it as a database table where the bits of information are stored as field values.
To help you visualize things better, imagine an object as a table. The columns represent the fields and the rows represent records. With objects, you have control over how to organize and view this data using features like page layouts and object permissions.
A lot of things can be done with objects, and like any product or service, Salesforce comes with out-of-the-box objects called standard objects which are available by default. Here are some examples:
- Accounts
- Contacts
- Cases
- Leads
- Opportunities
As you can see, the samples above are very common terms many businesses use. However, your organization is surely special and Salesforce’s standard objects will not always be the best fit for your needs. This is where custom objects take center stage.
Custom objects allow you to store information that’s unique to your organization. This gives you the capability to go beyond what standard objects have to offer. Custom objects can either be built by you or come as part of a package installed from the AppExchange.
Why Use Custom Objects?
Custom objects are great because having them means you can build custom fields and page layouts that control what to display to your end users. Access and sharing can be controlled by your org-wide defaults and sharing rules. Creating relationships with other objects is also possible. Aside from that, you can create reports and dashboards to review and analyze your data. Importing custom object records into your org is possible too.
By now you must be thinking, “Hey, all of this is great! How do I go about creating my first custom object?” See the video below where I created a custom object, “Pet Food”, for my small make-believe business, Pets in the City.
Now that we’ve tackled custom objects and how to create them, let’s move the spotlight to yet another widely-used feature in Salesforce: record types.
What Are Record Types?
What if I told you there’s a way to further customize your Salesforce objects for various use cases? Cool, right? Record types can give you this by differentiating the same object to individual users with the use of varying perspectives. It can also be seen as a way of grouping records within a single object to make things easier for the end user.
Record types are mainly used to implement different business process workflow requirements by changing the way a record is presented to your users depending on the role they play. Using record types, you can offer different picklist values, processes, and page layouts. One thing to keep in mind though is that record types do not provide security or access control. You are simply presenting a record differently, so permission is still determined by the OWD and sharing rules on said object.
Why Use Record Types?
Consider using record types when you want things to execute differently for each type. When there is a need for your users to follow separate business processes dealing with an object, record types automatically come to the rescue. They can also be used as criteria in formulas, flows, and validation rules, which will definitely come in handy when building automation.
Record types prevent your users from seeing unneeded fields when working on an object record. This reduces clutter in your org and also improves efficiency by reducing the time it takes to scroll through a page layout with so many fields taking up unnecessary space.
If you think record types are awesome, see how I used them to Pets in the City’s advantage in the video below:
Now that you know what each is generally used for, you’ll have a better grasp of how to set up custom objects and record types to best support your unique business needs. Here are some pointers to keep in mind when deciding between the two:
- A good first step is to look at the differences in the data you need to store, then estimate how far the current state is from your existing standard objects. Sometimes, you won’t even need to implement either of the two. A custom field is enough to determine small record differences when the data captured is almost the same for all records.
- Use custom objects when there is no standard object that can mostly represent the kind of information you need to store, or when the existing standard objects have required fields that your data does not need.
- Custom objects are called for when you cannot classify your information simply as a “type” of one of your existing objects, and the data requires an entirely new set of processes or fields.
- When there is a need to implement different business processes for the same object or display different fields according to the user, consider using record types.
- The ideal number or limit of record types to use in an object is 200. Keep this in mind when implementing record types – although, usually, this is more than enough for most businesses.
- A record with a certain record type is not hidden from a user who isn’t assigned to that record type. Record types do not determine visibility, and access is still controlled by the OWD and sharing rules for that object. Assigning the record type to a profile only gives the users the ability to create records with that record type.
- When adding new picklist values for objects with record types, always remember to add them to the record types as well! I have worked with users wondering why a picklist value appears for some records but is missing for others. It’s almost always because the picklist value was added later but was not added to all the record types where it’s needed.
- If you frequently use inline editing for list views, you might be surprised when that trusty pencil icon doesn’t appear on the fields of objects that have record types enabled. Unless you filter the list view to only display records from a single record type, inline editing won’t be possible.
Summary
Wow, that was a lot to take in for two simple features! Despite both custom objects and record types being considered as basic functionalities, they comprise a big chunk of your org’s foundation.
It may seem like using either of the two doesn’t matter much right now, but as your org grows older and more data is stored, you will begin to realize that using one when you could (and should) have used the other can complicate things in the future. It’s harder to clean up a cluttered org or optimize processes that your users have been doing for years, so the best move is always to plan and think one (or two!) steps ahead.
Comments: