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?
Out 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.
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?
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?