Important question: Do you know how to recognize that an object is not a standard object, but a custom one?
a) It has the name New Awesome Custom Object
b) It blinks green
c) Right next to the name, a little GIF of a dancing unicorn appears
d) It has an appendage in the API name: __c
Of course, the answer is d). Although I very much regret that there is no dancing unicorn. I don’t know about you, but I can already see it in my head. There’s another way – you simply look at the type of object in Object Manager, and there it’s written whether it is a standard or custom object. But that sounds too easy for us, right?
The last thing I would like to share with you in this section is best practices when creating a new object:
- The first is naming. Remember to make the name reflect the function of the object. It is very important that the user/administrator/developer knows what the new object is for. Avoid abbreviations.
- The second very important element is descriptions. Descriptions can save many a new administrator. Thanks to descriptions, a new employee can easily find their way in a new structure for them.
- Third is configuration. Design your object in your head, and think about sharing the object and access to its data. Your fields that will be mandatory and validations for the rest of the data will prevent chaos among the data, and you will take care of its quality.
- Fourth is documentation. No matter what you use, whether it is Confluence or maybe a document shared on Google Drive, fill it with new fields and settings. New people will be very grateful to you.
And so, we have come to the end of the section on standard and custom objects. After this chapter, you will know what they are and what they can be used for, how to create connections between such objects in two ways (master-detail and lookup), and how to recognize a custom object. In the next section, you will learn about the mysteriously sounding junction object.