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.
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

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

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).