In the previous chapters, you learned about the components of Salesforce. Indeed, it has meticulously written lines of code that look awesome after graphic processing. You also learned how the system is divided among its tenants, and what Classic and Lightning are. As you can see, some of the Salesforce elements are duplicated. The same goes for objects – we have standard and custom ones. Objects in this ecosystem are an absolute must-have, and it’s these two types you will learn about in this section. So, let’s get started.
To better illustrate the meaning of an object, imagine two warehouses with thousands of different products. In the first one, James, the chief warehouseman, is a disorganized person. Papers are scattered under his feet, products are strewn around the warehouse, and when an order comes in, he scratches his head, trying to find the right goods. On the other hand, in the second warehouse, there’s John. John loves order; he knows which box contains what. When an order comes in, it takes him 5 minutes to complete it. But getting back to objects. They are like John’s warehouse. Thanks to their fields, and properties, they can hold the relevant data. Entering the Contact object, you know well that you will find data such as first name, last name, or email address. And entering the product, you know that there will be product data such as the name and other elements associated with it.
If we already know what objects are, we can move on to their classification. In the Salesforce system, we have access to four types of objects. However, in this section, I will focus on two, which I believe are the most popular (you will find the rest in the next sections) – standard objects are those that we receive in the out-of-the-box version, which is available in a fresh Salesforce org. These objects have been designed to best reflect common business constructs. They are designed to represent sales processes and service processes. As a result, people who have been working in the Salesforce ecosystem for a longer time can offer their clients Salesforce clouds tailored to their needs. Standard objects have implemented the most necessary fields, which makes the implementation of CRM solutions relatively quick.
The most popular objects include the following:
- Account: Here, users store data of companies or organizations. Here, you will find the company’s location, email address, or publicly available phone number.
- Contact: This object stores data of people, often employees of a given company. In this object, you will find the first and last name, phone number, and date of birth.
- Opportunities: In other words, chance for a good deal. There users store data about the sale of a service/product. The name of the opportunity, the type of customer, the amount, or the close date are the fields that will be on the OOTB version of an opportunity in Salesforce.
Of course, I am talking here about basic Salesforce with Sales Cloud. If you switch to Service Cloud, you will find other objects dedicated to service processes.
Each of the standard objects can be customized to the needs of your company. For this, we use new fields that we can place on the object. We talked about fields in Chapter 3, remember? Thanks to this type of customization, we can even adapt standard objects to our needs.
As I mentioned, objects are a kind of container storing appropriate data. This data can be combined using two quite interesting, quite similar, but also quite different connections.
The first one is the master-detail relationship. This relationship is between two objects, and what is characteristic is that in this type of relationship, we can establish a hierarchy and dependency. Here, we set up a parent-child relationship, where the master object is the parent and the detail object is the child. This type of relationship has certain dependencies; the records of the detail object are always controlled by the records of the master object. To better understand, look at the following screenshot. We will use the entire community that loves events such as Comic Con. As you can see, in the next diagram, they are waiting for their special event, but at the last minute, the organizer cancels the event. And all the regular attendees go home:
Figure 5.1 – Children (attendees) with parent (special event); no children (attendees) without parent (special event)
Based on this example, if the parent in a master-detail relationship is deleted, the child records (detail-child) will also be removed. This is the opposite behavior to that in a lookup relationship. But about that in the following sections.
But are these all the important aspects of this relationship? Of course not. Another extremely important element is security. In a master-detail or parent-child relationship, the child inherits all security settings from the parent object (it’s a bit like a family; you can’t fool DNA). This means that the security and visibility settings of the master record object enforce the same rules on the detail records. And the relationship on the detail object is necessary to create a record. Without specifying a master record, you cannot create a new detail.