--- schema_version: "1" id: 6f286e6919ed15a0f7058005284efd9b20e743fdefcde2b012b1b66ee5e94734 title: Considerations for Object Relationships collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/relationships_considerations.md canonical_url: https://help.salesforce.com/s/articleView?id=platform.relationships_considerations.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 54addda6c4ddd3da6564b429bcc632acb590dc18164b66e03bd5102cb32452ec description: Review these considerations before creating relationships between objects. products: - Salesforce Platform - Security release: "264" --- # Considerations for Object Relationships Review these considerations before creating relationships between objects. ### Required Editions ![Important](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-extend_click-264-0-0-production-enus/5f7d9219-b7b1-4552-8891-f1aba9b289fc/images/icon_important.png) 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 permissions | These 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](https://help.salesforce.com/s/articleView?id=platform.dev_security.htm&release=264.0.0&type=5 "Learn how security settings work together so you can control access to your custom objects with great flexibility."). 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-extend_click-264-0-0-production-enus/5f7d9219-b7b1-4552-8891-f1aba9b289fc/images/icon_note.png) 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-extend_click-264-0-0-production-enus/5f7d9219-b7b1-4552-8891-f1aba9b289fc/images/icon_warning.png) 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 Type Standard Report Types Report 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-extend_click-264-0-0-production-enus/5f7d9219-b7b1-4552-8891-f1aba9b289fc/images/icon_important.png) 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 - [Object Relationships Overview](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm&release=264.0.0&type=5 "Create relationships to link objects with each other, so that when your users view records, they can also see related data. For example, link a custom object called Bugs to cases to track product defects that are associated with customer cases.") - [Create a Many-to-Many Object Relationship](https://help.salesforce.com/s/articleView?id=platform.relationships_manytomany.htm&release=264.0.0&type=5 "You can use master-detail relationships to model many-to-many relationships between any two objects. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. For example, you create a custom object called Bug that relates to the standard case object such that a bug could be related to multiple cases and a case could also be related to multiple bugs. When modeling a many-to-many relationship, you use a junction object to connect the two objects you want to relate to each other.") - [External Object Relationships](https://help.salesforce.com/s/articleView?id=platform.external_object_relationships.htm&release=264.0.0&type=5 "External objects support standard lookup relationships, which use the 18-character Salesforce record IDs to associate related records with each other. However, data that’s stored outside your Salesforce org often doesn’t contain those record IDs. Therefore, two special types of lookup relationships are available for external objects: external lookups and indirect lookups.")