The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including ADM-211: Administration Essentials for Experienced Admin Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

Extending Custom Objects and Applications : Relationships and Considerations

1. Object Relationships – Overview

Now that we have understood custom objects, fields, and field types, it's time for us to move on to object relationships. Objects being related to one another is a very common scenario in any CRM system. So, what do we mean when we say that objects are related to one another? Let's consider our data model. Here, we have six entities, right? At least, let's consider these major entities. Courses, students, instructors, departments, extracurricular activities These entities are definitely not independent entities, right? They are connected to each other. For example, in every course, there will be multiple students enrolled, right? So there is a connection between courses and students. Similarly, for every course, there will be an instructor, and the same instructor will handle more than one course, right? So courses and instructors are related to one another.Again, there are departments and extracurricular activities. Every student will have an extracurricular activity tagged for him or her. And every student will belong to a department, right? As a result, these entities are fundamentally linked. And how they are related is something we will learn more about. In Salesforce, there are different types of relationships that are available. First is the lookup relationship, the master detail relationship, the many-to-many relationship, the self relationship, the hierarchical external lookup, and the internal lookup relationship. But before we deep dive into these relationships, we need to understand one concept. That is, how are they related? What is the relationship type? whether it is one too many or many too many. So when we say one too many or many too many, what is that? It means how one object is related to another object. So that is the difference. For example, in our scenario, let's consider courses and departments. One course will be tagged for one department, right? However, one department offers multiple courses, right? Say, for example, strategic management. So strategic management is a course, and let's turn to maybe the MBA department, all right? So the strategic management course has the MBA department tacked to it.However, the MBA department offers not only a strategic management course, but other MBA courses, right? So one course has one department tacked on. However, the same department has multiple courses to offer. So this is a one-to-many relationship. One course record is associated with one department record. However, the same department record is associated with multiple course records. So this is the concept of a one-to-one relationship. Next is many-to-many relationships, right? One is too many. Now. many too many. in many too many relationships. Let's say courses and students. In one course, there will be multiple students enrolled, right? Definitely, there will be many students taking up one particular course. Similarly, one student will be enrolled in multiple courses. It works on both sides. One course has had multiple students. Similarly, one student has had multiple courses associated with him or her. So in this scenario, that is called a many-too-many relationship. This is the foundation we need to have in place before diving into the object relations that we have in Salesforce.

2. Lookup Relationship – Overview

Now let's discuss the lookup relationship. We already had an overview of the various relationships in the salesforce, right? Look up, master detail, many tomany self, hierarchical, external lookup, internallook up among all these relationships. First, let's discuss the lookup relationship. A lookup relationship is one that exists between two objects and their self-force, as well as the relationship type. We know there are two relationship types. That is one-to-many or many-to-many, right? Lookup relationships fall in the first category. That is one too many. So what is one too many? One record of one object would be related to multiple records of another object. That's a one-to-many relationship. A lookup relationship is a one-to-many relationship. So let's take a look at our data model and see which relationship is the lookup relationship. Here's the relationship between students and extracurricular activities. We have marked it as a lookup, right? And here are some of the other relationships. I have marked it as "master detail." But when we say that some relationships are look-ups and some relationships are master details, we should also understand that in real time. In real-time project experience, the customer is the one who decides what kind of relationship exists between two objects, two entities, because they understand the business process, right? So we basically understand the business process from them and decide whether a lookup or a master detail relationship is required. And in this scenario, let's consider that the relationship between student and extracurricular activity is a lookup relationship. So first of all, what is a lookup relationship? Lookup relationship is a relationship between a parent object and a child object, and how they are related is what defines it. In master data relationships, child records should be associated with a parent. However, in lookup, it is optional. Child records need not be associated with a parent. So what is the meaning? In a lookup relationship, when we define two objects as being related through a lookup relationship, it is a loose binding. The relationship is optional. It is not required that all child records be associated with the parent. No, that is a master-detail relationship. In the RUCAB relationship, it is optional. There can be many records in the system. It is not that all the child records are associated with a parent record. Some may, some may not. So that is a basic characteristic of a lookup relationship. Looking up relationships is therefore optional. where the master detail is more tightly bonded. It is mandatory. The next feature is cascade record deletion. So there is cascade record deletion in master detail. However, there is no cascade record deletion in Lookup. So when we talk about cascade record deletion, what is cascade record deletion? It means when a parent record is deleted, whether the child records are deleted or not, that is called a cascade record deletion. In cascade record deletion, the child record gets deleted. meaning in a master-detail relationship. When a parent record is deleted, all its related child records are also deleted. However, in Lookup, that is not the scenario, but we have some control over this cascade record deletion, which we'll be discussing later. However, the general feature is that MasterDetail allows cascade record deletion, while Lookup does not allow cascade record deletion. The next characteristic is that standard objects cannot be detailed objects; that is the child object. and here there are no such restrictions. In a lookup relationship, the parent object and the child object can be a standard object or a custom object. There are no such restrictions out here. However, in master-detail relationships, there may not be any restrictions for the parent object when it comes to the child object. That is a detailed object. Standard objects can't be detailed objects. All right, there are no restrictions on the parent object, though. But we have to note this particular restriction in master detail. The next characteristic is whenever we create a master-detail relationship. The Master Detail Relationship field is required on the page layout of the Detail object. However, this is a loose bond, so it is not necessarily required. And when we create a master detail relationship, we can create roll-up summary fields on the parent object as well, which will basically do a summary of the records of the detail object and populate it on the parent object. However, we cannot establish a roll-up summary field using a lookup relationship and tight bonding. The detailed object, or the detailed record, basically completely depends on the master record for all its sharing and security settings. However, it is independent. The parent record and the child record are independent in their sharing and security settings. So from this, we understand that MasterDetail is more of a tight bond. Lookup, on the other hand, is more of a loose bonding. And now that we have understood the basic characteristics and differences between a MasterDetail and Lookup relationship, let's go ahead and create a Lookup relationship in Salesforce. So in our data model, the example that we have taken is student and extracurricular activity. So when we have a student and an extracurricular activity, the parent object will be extracurricular. Then a child object could be a student. Multiple students may participate in the same extracurricular activity. However, one student can enrol himself or herself in only one extracurricular activity. All right, so this is how students and extracurricular activities are related. Now, you can ask me why one student can be in more than one extracurricular activity, right? But this is how the data model is. And this is how we have assumed—maybe because that particular educational institution operates that way, maybe they allow a student to have only one extracurricular activity. All right? So, as previously mentioned, it all depends on the business and how they have their business process. All right? So in our data model, the assumption is that one student can have only one extracurricular activity. However, there can be multiple students enrolled in a particular extracurricular activity. So this is our lookup relationship. Now let's replicate this relationship in Salesforce. So let's jump onto the Salesforce application. Step one would be to go to the child object. In our scenario, the child object is a student. So go to students, go to the object definition page, and let's create a relationship field. So custom fields and relationships We have only two fields already in there. Let's create a new relationship field. So hit the new button and select the lookup relationship. Hit Next, and it is related to: choose the parent object, and the parent object in our scenario is extracurricular. Hit Next. Fill in the details. While filling in the details, note these options that we have out here. I just let the child relationship name be as students. But then we have the other options that are available while creating this lookup relationship. So what is that requirement? Always require a value in this field in order to save a record. This is pretty similar to the required option that we have for the other fields. But if you choose this option only among the two options, do not allow deletion of the lookup record. Only that option is available. So what is the second option? The second option is that, so what happens when a lookup record gets deleted? Meaning, when a parent record gets deleted, what should happen to the child records? So there are two options that are available. The first option is to clear the value of this field. You can't choose this option if you make this field required. That is, when a parent record is deleted, the link between the parent and the child is also removed. That's the meaning of clearing the value of this field. However, if you make it required, this option is not available. You know that makes logical sense, right? because it is required. So this option doesn't make any sense here. And what is the second option? Do not allow deletion of the lookup record. That's part of the lookup relationship. This means that if you select this option, you will be unable to delete the parent record. If it has child records associated with it, the system would say that there are already records related to it. So you cannot delete this record. Though I am not explicitly showing you the error message or the warning message that is displayed in Salesforce, I highly, highly recommend you replicate this scenario and see the error message so you have a better learning experience. So among all these, let me stay with the default, let me not make it required, and let me choose to clear the value of this field. And there is also another optionwhich is called as Lookup Filters. Let's go over these lookup filters in more detail later. Once you're done giving all the values, hit Next and save the record. Perfect. So now we are done creating our first lookup relationship, and that is between students and extracurricular activities. So now let's see how this particular relationship behaves in the UI. So let me create a new student record, fill in the details, and now we can see a new relationship field. That is a lookuprelationship field extracurricular activity. And we have two extracurricular activities. All right, so now that a new student record is created and that particular student has this extracurricular activity assigned to him, this is how we create a lookup relationship. And this is in the "child" object, right? A student is a child object, and one student can have only one extracurricular activity. However, if you drill down to the parent object, that is, extracurricular activities, you will see a new related list created over here. That is, these many students have enrolled in this extracurricular activity, okay? However, now we have only one student. So please allow me to create another student record and associate that student. All right? So now that what we see here is this extracurricular activity, which is a community service activity, we see that two students are enrolled in it. That is, one parent record has two student records associated with it. However, one student record can have only one parent record associated with it. meaning one student can have only one extracurricular activity associated with it. So this is the overall concept of lookup relationships.

3. Considerations while using Lookup Relationship

The next relationship type that we are going to discuss is the master detail relationship. Among the different types of relationships available in Salesforce, we've already discussed the Lookup relationship. Now let's understand. What is the Master-Detail relationship? We know there are two relationship typesone to many and many to many. Among those, Lookup falls in the first category; that is one too many. Similarly, Master Detail also falls in the first category, which is one to many. So both Lookup and Master Detail fall into the "one to many" category. This means that one record of one object is linked to multiple records of another object. Look Up and Master Detail Faults both fall into this one-too-many category. However, they are different from each other in their characteristics. Let's understand the difference between them. Master detail and lookup. So Master Detail child records should be associated with a parent because of the tight bond. Lookup is basically a loose bonding system, meaning not all child records are associated with parents. There may be scenarios wherein child records are not associated with their parent records and cascade record deletion happens in MasterDetail, whereas it doesn't happen in Look Up. So whenever a master record is deleted, all its related detail records are also deleted. And the other important difference between MasterDetail and Look Up is about the detail object, that is, the child object. In the master detail relationship, the child object cannot be a standard object. So for any standard object, you cannot create a master detail relationship. However, there are no such restrictions in LookupRelationship or the Master Detail Relationship field that is required on the page layout. It is not required on the Lookup roll up.Summary fields can be created in Master Detail Relationships, whereas they cannot be established in Lookup Relationships. And in master detail relationships, the detail record inherits the sharing and security settings of its parent record. However, in the Lookup relationship, they are independent. They have no effect on security. Perfect. So, now that we understand the distinction between Master Detail and Look Up relationships, as well as the basic characteristics of a Master Detail relationship, let's take a look at our data model to see which is a Master Detail Relationship. This one is essentially about the relationship between an instructor and a department. meaning every instructor is associated with a department. However, one department will have many instructors, obviously. Right? So this is a relationship between an instructor and a department. Now, let's replicate this relationship in the Salesforce UI. So the Open Salesforce application navigates to the child object. In our scenario, the child object is an instructor. So go to instructors and let's create a new relationship field. So go to the Object Definition Page. Let me create a new relationship field. We know the relationship field is always created on the Detail object, which is the child object. And here the relationship type would be "Master Detail." So select Master Detail Relationship, and now choose the parent object here. Departments will be the parent object in our case. Next, fill in the details. Also, while filling in the details, note theoptions that we have while creating this relationship. If you recall, when we created a lookup relationship, we had the option of making that field required or clearing the value of the field when the parent record was deleted. Also, how should the parent record be recorded and whether the system should allow it? So those were the options available to us while creating lookup relationships. However, in Master Detail Relationship, there is an option for sharing settings. So this option decides what the minimum access level is that is required on the master record to create, edit, or delete related detailed records. meaning only users who have at least read access to the master record can create, read, or delete the related detailed records, or users with read/write access to the master record can create, edit, or delete the related detailed records. So this again depends on the business process and how it is defined. So based on that, choose the read-only option or the rewrite option. And also, there is an option for parenting repair, wherein the child's records can be repaired to the other parent's records after they are created. And as I generally say, all these options are available for you to try out and see how they behave in the UI so that we can enhance our learning experience. and a look-up filter. We discussed the Lookup filter in detail in the previous video. So we have the option of having the filter criteria and logic applied to records when they actually apply. And finally, once we define everything, we can enable the filter to take its action, right? Similarly, that look-up filter option is available here in Master Detail as well. So once you're done configuring all these, let's go ahead and save the relationship. Perfect. So what does the system say? The system says that you cannot create a master detail relationship on an existing custom object if a record already exists. So for which object are we trying to create this master-detail relationship? We are trying to create it in the instructor object, right? So in instructors' objects, we already have data. So for an object that already has data, it is not possible for us to create a new master digital relationship. So there are two ways to work around this. One is to delete the data in the instructors object and then create it fresh. The second option would be to create a lookup relationship and then convert it to a master digital relationship. The second option is the most practical and logical, because it is not possible to delete records in real time, in real-time projects, just to create a master digital relationship. So what we generally do is create a lookup relationship and then convert it to a master detail. So now let's go ahead and create a lookup relationship. However, keep in mind that creating a master-detail relationship for objects where there is no data will be simple and straightforward. However, with this object having data, we have to do a workaround by creating the lookup. So go to the object and create a lookup relationship. Now we are done creating our lookup relationship field. So let me go and change the field type from Lookup to Master Detail. So edit the field, hit change field type, and there you would have just the other option, which is master detail relationship. Hit next, and then it gives us the same options that we had while creating a master detail relationship. Hit save. Perfect. So now that we have converted our lookup to a Master Detail relationship, this is actually a workaround. As I mentioned before, the straight way would be to create a master-detail relationship, and that would happen on objects wherein there is no data. However, this is a work around.When an object has data, you create a lookup relationship, populate all the records with the data, and then convert it to a master detail.

4. Master-Detail Relationship – Overview

The next relationship type that we are going to discuss is the master detail relationship. Among the different types of relationships available in Salesforce, we've already discussed the Lookup relationship. Now let's understand. What is the Master-Detail relationship? We know there are two relationship typesone to many and many to many. Among those, Lookup falls in the first category; that is one too many. Similarly, Master Detail also falls in the first category, which is one to many. So both Lookup and Master Detail fall into the "one to many" category. This means that one record of one object is linked to multiple records of another object. Look Up and Master Detail Faults both fall into this one-too-many category. However, they are different from each other in their characteristics. Let's understand the difference between them. Master detail and lookup. So Master Detail child records should be associated with a parent because of the tight bond. Lookup is basically a loose bonding system, meaning not all child records are associated with parents. There may be scenarios wherein child records are not associated with their parent records and cascade record deletion happens in MasterDetail, whereas it doesn't happen in Look Up. So whenever a master record is deleted, all its related detail records are also deleted. And the other important difference between MasterDetail and Look Up is about the detail object, that is, the child object. In the master detail relationship, the child object cannot be a standard object. So for any standard object, you cannot create a master detail relationship. However, there are no such restrictions in LookupRelationship or the Master Detail Relationship field that is required on the page layout. It is not required on the Lookup roll up. Summary fields can be created in Master Detail Relationships, whereas they cannot be established in Lookup Relationships. And in master detail relationships, the detail record inherits the sharing and security settings of its parent record. However, in the Lookup relationship, they are independent. They have no effect on security. Perfect. So, now that we understand the distinction between Master Detail and Look Up relationships, as well as the basic characteristics of a Master Detail relationship, let's take a look at our data model to see which is a Master Detail Relationship. This one is essentially about the relationship between an instructor and a department. meaning every instructor is associated with a department. However, one department will have many instructors, obviously. Right? So this is a relationship between an instructor and a department. Now, let's replicate this relationship in the Salesforce UI. So the Open Salesforce application navigates to the child object. In our scenario, the child object is an instructor. So go to instructors and let's create a new relationship field. So go to the Object Definition Page. Let me create a new relationship field. We know the relationship field is always created on the Detail object, which is the child object. And here the relationship type would be "Master Detail." So select Master Detail Relationship, and now choose the parent object here. Departments will be the parent object in our case. Next, fill in the details. Also, while filling in the details, note the options that we have while creating this relationship. If you recall, when we created a lookup relationship, we had the option of making that field required or clearing the value of the field when the parent record was deleted. Also, how should the parent record be recorded and whether the system should allow it? So those were the options available to us while creating lookup relationships. However, in Master Detail Relationship, there is an option for sharing settings. So this option decides what the minimum access level is that is required on the master record to create, edit, or delete related detailed records. meaning only users who have at least read access to the master record can create, read, or delete the related detailed records, or users with read/write access to the master record can create, edit, or delete the related detailed records. So this again depends on the business process and how it is defined. So based on that, choose the read-only option or the rewrite option. And also, there is an option for parenting repair, wherein the child's records can be repaired to the other parent's records after they are created. And as I generally say, all these options are available for you to try out and see how they behave in the UI so that we can enhance our learning experience. and a look-up filter. We discussed the Lookup filter in detail in the previous video. So we have the option of having the filter criteria and logic applied to records when they actually apply. And finally, once we define everything, we can enable the filter to take its action, right? Similarly, that look-up filter option is available here in Master Detail as well. So once you're done configuring all these, let's go ahead and save the relationship. Perfect. So what does the system say? The system says that you cannot create a master detail relationship on an existing custom object if a record already exists. So for which object are we trying to create this master-detail relationship? We are trying to create it in the instructor object, right? So in instructors' objects, we already have data. So for an object that already has data, it is not possible for us to create a new master digital relationship. So there are two ways to work around this. One is to delete the data in the instructors object and then create it fresh. The second option would be to create a lookup relationship and then convert it to a master digital relationship. The second option is the most practical and logical, because it is not possible to delete records in real time, in real-time projects, just to create a master digital relationship. So what we generally do is create a lookup relationship and then convert it to a master detail. So now let's go ahead and create a lookup relationship. However, keep in mind that creating a master-detail relationship for objects where there is no data will be simple and straightforward. However, with this object having data, we have to do a workaround by creating the lookup. So go to the object and create a lookup relationship. Now we are done creating our lookup relationship field. So let me go and change the field type from Lookup to Master Detail. So edit the field, hit change field type, and there you would have just the other option, which is master detail relationship. Hit next, and then it gives us the same options that we had while creating a master detail relationship. Hit save. Perfect. So now that we have converted our lookup to a Master Detail relationship, this is actually a workaround. As I mentioned before, the straight way would be to create a master-detail relationship, and that would happen on objects wherein there is no data. However, this is a work around.When an object has data, you create a lookup relationship, populate all the records with the data, and then convert it to a master detail.

5. Considerations while using M-D Relationship

Now that we have a good understanding of master detail relationships, how to create them, and how to use them, let's see what all the various considerations are while using master detail relationships. First, a master-detail relationship feels like it is required. required on the page layout of the Detail object? Yes. We know that whenever we create a master digital relationship field in a detailed object, that field automatically becomes required on the layout because there is a tight bonding between the master and the detailed object. so it is required. Makes sense. Repairing option Yes, the option to repair is available by default, but you have the option to select it and make it available. So, what is "repairing"?The child record can be regrouped with a different parent record. So that is the concept of repairing it. In our example, in an instructor record, "instructor" is related to "department," right? The instructor is a child, and the department is the parent. And this particular instructor record is already associated with the department record. That is informatics. And now, when I try to edit this record, you see that a department is not editable. meaning a reparenting option was not selected. so it is not by default. However, there is an option to check that field while creating the master detail relationship to allow reparanting. Or we can edit it at any point in time. So once that option is checked, this field becomes editable, meaning you can regroup this particular child record to a different parent record. In that case, this field becomes required on page layout two. So this is the option for reparenting. The next consideration is Roll up Summary fields can be created. Yes, master. Detail relationships, support, and roll up summary fields So, what is the Roll Up Summary field? A roll-up summary field is basically a field type that is created on the parent object and helps summarise the values of its related child records. When a parent object is linked to a child object via a master detail relationship, roll-up summary fields are automatically created on the parent object. In our scenario, the parent object is a department, and it has many instructors to it.That is, a child's object is an instructor. So now, if we try to create a field in the Department's object, you can see this Roll-up Summary field type. This is enabled. So this field type, Roll Up Summary," will be enabled only for objects if they act as apparent objects in a Master Detail Relationship. For other objects, it wouldn't be enabled. Say, for example, extracurriculars. If I try to create a field in an extracurricular object, we do not see this option enabled. Why? because it isn't a masterobject in any master-detail relationship Moving on. Master objects can be standard or custom. Detailed objects can only be custom objects. Yes. So master objects can be standard objects or custom objects. However, that's not the exception here. Not all standard objects are users or and Lead.So, other than User and Lead, any standard object can be a master object. And there are no restrictions, such as those on custom objects. And when considering detailed objects, it can only be custom objects. Standard objects cannot act as detailed objects for the Master Detail Relationship. Moving on. On Detail Records, the Owner field is not available. Yeah, it makes sense because it basically inherits all its sharing and security settings from the parent record. Right, so they do not have an owner field because it is populated from the parent record. Again, in our scenario, the child record is with the instructors. So if I go to the instructor record, I do not see any owner field in the child record because it is automatically inherited from the parent record. And here in our scenario, the parent record is Department, and it has an owner. Yeah, because it is a master record. However, the detailed records do not have the "owner field populated in them. Next, multi-level master-detail relationships are possible. Yes. So when we say there is a master object and it is related to a detailed object that forms one level of relationship, similarly, it can go up to three levels of multilevel master detail relationships. And we should also note that this multilevel master-detail relationship can also be used in reports. Moving on. Detailed objects cannot have sharing rules, manual sharing, or queues. Yes, in master-detail relationships, there is basically a tight bond between the master object and the detailed object. The Detail object basically inherits all the sharing and security settings from the Master object, so it cannot have separate sharing rules of its own. Let's quickly check it out in the UI. Go to Sharing settings. In our scenario, Department is the parent object, and Instructors is the child object. Right? So that's the reason we are not able to see any sharing rules specifically for instructors. However, we see sharing rules for departments, extracurricular activities for courses, and the other custom objects that we created. However, we do not see Instructor here because Instructor is a detailed object and it cannot have sharing rules of its own. So basically, the detailed object inherits all the sharing and security settings from its parent. In fact, whenever a Master Detail Relationship is created automatically, the detailed object's OWD setting is changed to control by parent. So in our case, the detailed object is instructors. So let's quickly share the OWD settings of instructors and instructors controlled by parents. We did not update that. Once it becomes a detailed object of any master detailed relationship controlled by parents, the system automatically updates. In this scenario, the parent is a Department object. So all the sharing and security settings of the detail record are inherited from the parent record. Perfect. A master object can be deleted. However, detailed objects can. Yes, we cannot delete a custom object that acts as a master in a master detail relationship; however, we can delete the detail object. But in that scenario, when we delete a detailed object, what happens is the master detail relationship automatically gets converted to a lookup relationship. And how about deleting records? Deleting a master record also deletes related details and sub-detail detail record.We are well aware of this. So this is the concept of cascade deletion. Whenever the parent record gets deleted, all related child records also get deleted. So when we say sub-detail records, it means the next level of the hierarchy is master-detail, and that detail acts as a master. So in that case, like we say, it is a sub-detailed record. So whenever a master record gets deleted, all its related detail and sub-detail records also get deleted at the same time. If we undelete a master record, then it undeletes the related detail and subdetail records as well. And the last one is about reports. So whenever a master detail relationship is created between two objects, an automatic standard report type also gets created. This is pretty similar to the lookup relationship. When we create a master detail relationship, we automatically create a standard report type. Here we are in the Reports tab, and when we try to create a report and attach a report type, I see a department with Instructors This report type is available because there is a master-detail relationship between reports and departments and instructors. So these are the various considerations that we need to have in mind while creating and using master-detail relationships.