Loading
Salesforce now sends email only from verified domains. Read More
Extend Salesforce with Clicks, Not Code
Table of Contents
Filter by (0)Add
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

            Search all of Salesforce Help
            Search all of Salesforce Help
            Considerations for Object Relationships

            You are here:

            1. Salesforce Help
            2. Docs
            3. Extend Salesforce with Clicks, Not Code

            Considerations for Object Relationships

            Review these considerations before creating relationships between objects.

            Required Editions

            Important
            Important Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations.
            Available in: both Salesforce Classic and Lightning Experience

            Available in: Contact Manager, Group, Professional, Enterprise, Performance, Unlimited, Developer, and Database.com Editions

            Salesforce Connect external objects are available in Developer Edition and for an extra cost in Enterprise, Performance, and Unlimited Editions
            Relationship Limits
            Each custom object can have up to 2 master-detail relationships and many lookup relationships. Each relationship is included in the maximum number of custom fields allowed.
            Converting Relationships
            You can convert a master-detail relationship to a lookup relationship as long as no roll-up summary fields exist on the master object.
            Converting a master-detail relationship to a lookup for a custom object on the “detail” side, changes the organization-wide default for the object to public read/write.
            You can convert a lookup relationship to a master-detail relationship if the lookup field in all the records contains a value.
            A lookup relationship can’t be changed to a master-detail relationship if the organization-wide default of the child object access level in the relationship is Controlled by Parent.
            Converting a lookup to a master-detail-relationship changes the organization-wide default to Controlled by Parent and the sharing model is updated to public read/write.
            Self-Relationships
            You can create a relationship from an object to itself, but it must be a lookup relationship, and a single record can’t be linked to itself. However, a record can indirectly relate to itself. For example, the Holiday Promotion campaign can select the Direct Mail campaign in the lookup relationship, and the Direct Mail campaign can select the Holiday Promotion campaign in the lookup relationship.
            You can’t create a many-to-many self-relationship, that is, the two master-detail relationships on the junction object can't have the same master object.
            Icons for Custom Related Lists
            The icon you select for the associated custom tab also displays in any custom-related list you create based on a relationship.
            Custom related lists don’t include an icon if they’re based on a relationship with a custom object that doesn’t have a custom tab.
            Master-Detail Relationships
            To create multilevel master-detail relationships, you need the Customize Application user permission.
            When you define a master-detail relationship, the custom object on which you’re working is the detail side. Its data appears as a custom related list on page layouts for the other object.
            By default, records can’t be reparented in master-detail relationships. Administrators can, however, allow child records in master-detail relationships on custom objects to be reparented to different parent records by selecting the Allow reparenting option in the master-detail relationship definition.
            You can have up to 3 custom detail levels.
            Standard objects can’t be on the detail side of a custom object in a master-detail relationship.
            An object can appear one time in multilevel master-detail relationships. For example, a subdetail object in one multilevel master-detail relationship can’t also be the owner of the master object in another multilevel master-detail relationship. A subdetail object can’t also be the master object of the subdetail object’s detail object.
            Multilevel master-detail relationships don’t support division transfers.
            You can’t create a master-detail relationship if the custom object already contains data. You can, however, create the relationship as a lookup and then convert it to master-detail if the lookup field in all records contains a value.
            Converting relationships from lookup to master-detail, or from master-detail to lookup, behaves the same as for two-object master-detail relationships. That is, the two linked objects in the detail-subdetail1 or subdetail1-subdetail2 relationship have the same conversion limits as the master-detail relationship.
            Roll-up summary fields work as in two-object master-detail relationships. A master can roll up fields on detail records; however, it can’t directly roll up fields on subdetail records. The detail record must have a roll-up summary field for the field on the subdetail record, allowing the master to roll up from the detail’s roll-up summary field.
            You can use multilevel master-detail relationships in custom report types. The Allow Reports checkbox must be selected when you create the custom object. Custom report types created for multilevel master-detail relationships count toward the organization’s custom report type limit, and no reports generate if this limit is exceeded.
            Custom junction objects can’t have detail objects. That is, a custom junction object can’t become the master object in a multilevel master-detail relationship.
            You can’t delete a custom object if it is on the master side of a master-detail relationship. If you delete a custom object that is on the detail side of a master-detail relationship, the relationship is converted to a lookup relationship.
            Deleting a detail record moves it to the Recycle Bin and leaves the master record intact; deleting a master record also deletes related detail and subdetail records. Undeleting a detail record restores it, and undeleting a master record also undeletes related detail and subdetail records. However, if you delete a detail record and later separately delete its master record, you can’t undelete the detail record, as it no longer has a master record to relate to.
            A Metadata API deployment that includes Master-Detail relationships deletes all detail records in the Recycle Bin in these cases.
            • For a deployment with a new Master-Detail field, soft delete (send to the Recycle Bin) all detail records before proceeding to deploy the Master-Detail field, or the deployment fails. During the deployment, detail records are permanently deleted from the Recycle Bin and can’t be recovered.
            • For a deployment that converts a Lookup field relationship to a Master-Detail relationship, detail records must reference a master record or be soft-deleted (sent to the Recycle Bin) for the deployment to succeed. However, a successful deployment permanently deletes any detail records in the Recycle Bin.
            As a best practice, don’t exceed 10,000 child records for a master-detail relationship.
            A profile or a permission set can have an entity, such as Account, with a master-detail relationship. A broken permission dependency exists if the child entity has permissions that the parent should have. Salesforce updates the parent entity for a broken permission dependency on the first save action for the profile or permission set.
            If the child entity has these permissionsThese permissions are enabled on the parent entity
            Modify All Records OR View All Records View All Records
            View All Records OR Read Read
            Many-to-Many Relationships
            Junction object records are deleted when either associated master record is deleted and placed in the Recycle Bin. If both associated master records are deleted, the junction object record is deleted permanently and can’t be restored.
            Sharing access to a junction object record is determined by a user’s sharing access to both associated master records and the Sharing Setting option on the relationship field. See Custom Object Security. For example, if the sharing setting on both parents is Read/Write, then the user must have Read/Write access to both parents in order to have Read/Write access to the junction object. If the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read access to the junction object.
            In a many-to-many relationship, a user can’t delete a parent record if there are more than 200 junction object records associated with it and if the junction object has a roll-up summary field that rolls up to the other parent. To delete this object, manually delete junction object records until the count is fewer than 200.

            The first master-detail relationship that you create on your junction object becomes the primary relationship. This relationship affects junction object records in these ways.

            • Look and feel: The junction object’s detail and edit pages use the color and any associated icon of the primary master object.
            • Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship don’t have a visible Owner field, this is only relevant if you later delete both master-detail relationships on your junction object.
            • Division: If your organization uses divisions to segment data, the junction object records inherit their division from their associated primary master record. Similar to the record ownership, this is only relevant if you later delete both master-detail relationships.

            The second master-detail relationship you create on your junction object becomes the secondary relationship. If you delete the primary master-detail relationship or convert it to a lookup relationship, the secondary master object becomes primary.

            Roll-up summary fields that summarize data from the junction object can be created on both master objects.
            Formula fields and validation rules on the junction object can reference fields on both master objects.
            You can define Apex triggers on both master objects and the junction object.
            A junction object can’t be on the master side of another master-detail relationship.
            You can’t create a many-to-many self-relationship, that is, the two master-detail relationships on the junction object can’t have the same master object.
            Lookup Relationships
            If the lookup field is optional, you can specify one of three behaviors to occur if the lookup record is deleted:
            • Clear the value of this field—This is the default. Clearing the field is a good choice when the field doesn’t have to contain a value from the associated lookup record.
            • Don’t allow deletion of the lookup record that’s part of a lookup relationship—If you have dependencies built on the lookup relationship, such as a workflow rule, this option doesn’t allow the lookup record to be deleted.
              Note
              Note Deleting a record that has child records isn’t allowed, except when the child records are soft-deleted (sent to the Recycle Bin). If all the child records of a parent record are soft-deleted, then the parent record is deleted. Furthermore, any soft-deleted children are then removed from the recycle bin and permanently deleted.
            • Delete this record also—Available only for a custom lookup field on a custom object. This option isn’t available for a custom lookup field that refers to a standard object. Choose when the lookup field and its associated record are tightly coupled and you want to completely delete related data.
              Warning
              Warning Choosing Delete this record also can result in a cascade-delete. A cascade-delete bypasses security and sharing settings, which means users can delete records when the target lookup record is deleted even if they don’t have access to the records. To prevent records from being accidentally deleted, cascade-delete is disabled by default. Contact Salesforce to get the cascade-delete option enabled for your organization.

              Cascade-delete and its related options aren’t available for lookup relationships to standard objects.

            In a chain of lookup relationships, these behaviors work independently on each target field at each level. Say, for example, field A is the target lookup of field B, which in turn is the target lookup of field C. You can have a delete restriction on A and none on B, which means that A can’t be deleted but B can. After B is deleted, the relationship between A and B no longer exists and C holds an empty value for the lookup.
            In a multilevel lookup relationship, these options can conflict. For example, if field A is the target lookup of field B, which in turn is the target lookup of field C, you can specify that A deletes B, but B can’t be deleted because it’s in a relationship with C. If you try to delete A, you get an error that B can’t be deleted because it’s linked to C.
            If the parent record in a lookup relationship is deleted, the field history tracking for the child record doesn’t record the deletion. For example, if a parent account is deleted, the Account History related list for the child account doesn’t show the deletion.
            You can’t select indirect lookup fields in the parent field when you add the Related List - Single component to a Lightning Page. Instead, select the related list that’s associated with the indirect lookup field. It doesn’t show data in the related list, but shows the lookup field with no issue.
            Relationships on External Objects
            Lookup, external lookup, and indirect lookup relationships have some special behaviors and limitations.
            • Only lookup, external lookup, and indirect lookup relationships are available for external objects. No other relationship types are supported.
            • Depending on the availability of the external system, related lists of child external objects can load slowly when users view the parent record detail pages.
            • Relationships that involve external objects allow users to create child records from the record detail pages of parent records. However, the relationship field on each new child record isn’t automatically populated to identify the parent record.
            • Syncing doesn’t create relationship fields on the external objects in your Salesforce org. However, you can change the field type of a sync-created custom field to Lookup Relationship, External Lookup Relationship, or Indirect Lookup Relationship. Changing the field type of an existing custom field is simpler and more efficient than manually creating a relationship field on the external object.

              For example, suppose that the external system has a foreign key relationship. Syncing the related tables creates a text field in your org for the external column that identifies the foreign keys. To reflect the foreign key relationship within your org, change the field type of that text field to External Lookup Relationship.

            • A relationship field is a type of custom field. Therefore, like all custom fields on an external object, relationship fields can be overwritten when you sync the external object. See the sync considerations for each Salesforce Connect adapter that you use.
            • Cascade-delete isn’t available for external object relationships.
            • In Salesforce Classic, indirect lookup relationship fields don’t display the expected names of parent records. Instead, each indirect lookup relationship field displays the value of the target field on the parent object. To find related records, target field values are matched against the values of the indirect lookup relationship field on the child object. The target field, which has the External ID and Unique attributes, is selected when an indirect lookup relationship field is created.
            • In Salesforce Classic, external lookup relationship fields don’t always display the expected names of parent records.
              • In a list view, an external lookup relationship field displays the parent object ID or the value of the parent object’s External ID standard field. The latter appears by default, but if a custom field on the parent object has the Is Name Field attribute, the parent object ID is displayed.
              • In a record detail page, an external lookup relationship field displays the name as expected if the org has previously retrieved the parent record. If you see an ID in an external lookup relationship field, reload the page to replace the ID with the name.
            • Lookup search isn’t available for external lookup relationship fields. To edit an external lookup relationship field, manually enter the value of the External ID standard field for the parent record. This limitation doesn’t apply when the parent external object is associated with the cross-org adapter for Salesforce Connect.
            • Lookup search isn’t available for indirect lookup relationship fields. To edit an indirect lookup relationship field, manually enter the value of the target field of the parent record. The target field is the custom field with External ID and Unique attributes that was selected when the indirect lookup relationship was created. To determine related records, Salesforce matches target field values against the values of the indirect lookup relationship field on the child object.
            • With external lookup and indirect lookup relationships, the parent record appears as a clickable link in the relationship field on the child record. If the child record is viewed by a user who doesn’t have access to the parent record, the parent record appears in the relationship field as plain text instead of a link.
            • Lookup filters aren’t available for external lookup relationship fields.
            • Indirect lookup relationship fields can be created on external objects only.
            • Only objects that have a custom field with the External ID and Unique attributes are available as parent objects in indirect lookup relationships.If you don’t see the desired object when you create an indirect lookup relationship field, add a custom unique, external ID field to that object.
            • If the external system uses case-sensitive values in the specified External Column Name, make sure that the parent object field is also case-sensitive. When you define the parent object’s custom field, select External ID, Unique, and Treat "ABC" and "abc" as different values (case sensitive).
            Impact of Relationships on Reports
            The type of relationship you create affects which standard report types are available and how they’re categorized. These report types determine which related objects can be included in the report.
            • Lookup relationships allow data from the two related objects to be joined in one report.
            • Master-detail relationships allow data from three objects to be joined in one report: the master object, the detail object, plus one other lookup object. If the detail object has multiple lookup relationships, a separate report type is available based on each lookup.

            • Many-to-many relationships provide two standard report types that join the master objects and the junction object. The order of the master objects in the report type is important. The master object listed first determines the scope of records that can be displayed in the report.

              • “Primary master with junction object and secondary master” in the primary master object’s report category.
              • “Secondary master with junction object and primary master” in the secondary master object’s report category.
            The reporting impact of each relationship type is summarized in this table.
            Relationship TypeStandard Report TypesReport Type Category
            Lookup

            Object by itself

            Object with first lookup

            Object with second lookup

            Object with third lookup

            		 Based on the object
            Master-Detail

            Master object by itself

            Master object with detail object

            Master object with detail object and first lookup

            Master object with detail object and second lookup

            Master object with detail object and third lookup

            		 Master object
            Many-to-Many

            Primary master object by itself

            Secondary master object by itself

            Primary master object with junction object and secondary master object

            Secondary master object with junction object and primary master object

            Primary master object

            and

            Secondary master object
            Custom report types give you more flexibility to join data from multiple objects, including lookups and master-detail relationships.
            Important
            Important Converting a relationship from lookup to master-detail or vice versa can cause existing custom reports to become unusable due to the different standard report types available for each type of relationship. We recommend that you test your custom reports immediately after converting the relationship type. If you revert your relationship back to the original type, the reports are restored and become usable again.

            See Also

             
            Loading
            Salesforce Help | Article