Does it really have to be called a Custom Object?

Salesforce is weird. Okay, stick with me for a minute. Here is a platform that can be customized with clicks, no developer required. You can do a whole lot, in fact entire orgs can be designed and implemented without a single bit of code. Take just about any other major software option out there. If you want to customize it, you had better employ a host of developers ready to write code. There will be a long development life cycle and your business is at the mercy of IT. In the world of IT, Salesforce is a unicorn.

And herein lies the problem. Salesforce sells its product as being able to accomplish many business processes with Out of the Box functionality. And in their world, they speak the truth. A custom object, custom field, even a process builder is clicked based configuration of out of the box tools. No code is required. However, when Salesforce tells IT that this is all Out of the Box functionality, they look at that expression in the light of what that means with other products. For consultants this can cause confusion and tension. So do we really have to call the custom objects?

Silver toaster with 2 toasted pieces of bread half out of the toasterOut of the Box

Salesforce has three levels of features. Let’s think about them in terms of household appliances. Our first group is the out of the box components. If I walk into a store and purchase a toaster, when I get home, I open the box, plug it in and I am ready to make toast. I can adjust the settings but I do not have to and I will get toast. It may make my toast too light or too dark but it is nonetheless ready to use.

Salesforce out of the box features start with the basics like standard objects and standard fields. The first time I access my org, I can start inputting data into these fields. I may want to make adjustments to the page layouts, just like I adjust the settings on my toaster, but I don’t have to and I will still be able to store data in those fields. I have little control over some of the out of the box functionality, like the newly released deep clone functionality and syncing of quotes, I can either use it or not use it but I can’t change it. My toaster has a bagel setting. It toasts only the inside of the bread when this feature is used. I cannot change it to do just the outside. I either use it or I do not.

On a return trip to the store, I pick up a blender. When I pull the blender out of the box, I have to put it together, making sure the gaskets are in the right spot and the blade is settled in. There are out of the box features of Salesforce, like assignment rules, territories, and queues, that require me to do a little assembly. I am not customizing my blender, I am just putting the pieces together. With assignment rules, I am adding my data to the system so that Salesforce knows the criteria for running the assignment rules.

ConfigurationSmall red vacuum clear canister filled with water with hose and floor sweeper

On my next trip to the store, I pick up a vacuum cleaner. My vacuum cleaner comes with a whole lot of “parts” and a very nice storage bag for all of these different pieces. The vacuum manufacturer provided me with the pieces they thought I would need to do the majority of the cleaning in my house but it is up to me to decide which pieces to put together to accomplish my goal. One of the biggest benefits to Salesforce is its flexibility to be customized without the use of code. All of these “custom” features are like all of my accessories. I have at hand the ability to create custom object, custom fields, process builders, page layouts, custom permissions, and much more without a single line of code. The ability to do this is out of the box but the custom object is not technically out of the box. The business is able to do most of this work without any assistance from IT. And many admins do not come from a IT or computer science background. So is a custom object really custom in light of what custom means to IT or is it just a configured object?

pile of multi-colored legos


My final trip to the store takes me to buy… legos. Very few household appliances allow you the level of freedom that custom code does when it comes to changing Salesforce. Customization through code is like taking legos and building the appliance. In the world of Salesforce, bringing in a developer to write code, is bringing in the big guns to customize the functionality. Other than the fact that Salesforce understands them, there is nothing out of the box about triggers, apex classes, batch jobs, lightning components, and any other code your developer writes.

So the next time you have to have a conversation about why something that Salesforce says can be accomplished with out of the box functionality, hopefully being able to reference the vacuum and its many accessories to explain how a custom object is something that you get to use a few clicks to set up out of the box. What analogies do you use to help alievate the confusion of custom objects being out of the box when talking with your team?



  1. PJ Mann says:

    I am not sure I agree with you on this one. You have standard objects and custom objects, yes. I think about this like a car.
    You buy your car at the dealer. Its out of the box, fine. You do not like the wheels, so you get….CUSTOM WHEELS and so on and so forth.
    As you know when a FUNCTIONALITY can’t be accomplished OUT OF THE BOX then we do CUSTOM CODING, no declarative. The world of SALESFORCE is already complex and I am for simplifying it, maybe I am one of the few..

    • Kristi Dellinger says:

      I agree that when it is not out of the box, you do custom coding. I think where things get confusing to those from outside of the Salesforce world but who have an IT background is the custom object, custom field, etc. The customizable components that come out of the box. To those of us deeply immersed in the Salesforce world, we hear custom object and think, declarative functionality. To those who come from another product and hear custom object, they think code. When Salesforce sells the platform to the client saying this can all be done “OOTB” then the consultant says we’re adding Custom Objects, they can become confused about why that custom object is required if Salesforce does what they needed OOTB. Its a lot like, being an American English speaker, going to the UK and becoming confused by an expression that means one thing in the US and another in the UK. And we have to talk about the different meanings in order to understand each other.

  2. Richard Clark says:

    Kristi, as someone who does have a Computer Science background I can share that the idea of Custom does not intuitively mean development. Most other products would simply say they are extensible, a plugin architecture or have APIs for development. Customising an app normally precludes coding.

    So the use of Custom in Salesforce IMHO is actually implying declarative changes. In that sense I feel it does fit your analogies. When someone creates a spreadsheet, including formulas, it’s true to say Excel can meet the requirement out of the box via configuration/customisation. If I have to buy or develop a 3rd party plugin to do what I want then it’s not.

    Oddly, I was expecting this article to bemoan the use of the word Object, which I agree is a very developer term. In that sense it’s also a misnomer as it implies a false alignment to Object Orientation. I’ll leave the linguists to comment if it’s a valid term for English grammar reasons.

Leave a Reply

Your email address will not be published. Required fields are marked *