1. Object Relationship

https://help.salesforce.com/HTViewHelpDoc?id=relationships_considerations.htm

---

Relationship Limits

Each custom object can have up to two 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.

You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value.

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 have the Direct Mail campaign selected in the lookup relationship, and the Direct Mail campaign can have the Holiday Promotion campaign selected 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 do not include an icon if they are based on a relationship with a custom object that does not 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 are working is the “detail” side. 

Its data can appear 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 three 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 once 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 do not 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. To achieve this, 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 checked when you create the custom object. 

Custom report types created for multilevel master-detail relationships count towards the organizations custom report type limit and no reports are generated 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 cannot undelete the detail record, as it no longer has a master record to relate to.

As a best practice, don't exceed 10,000 child records for a master-detail relationship.

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, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write 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 you create on your junction object becomes the primary relationship. This affects the following for the junction object records:

• 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 do not 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 does not 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 
  This option restricts the lookup record from being deleted if you have any dependencies, such as a workflow rule, built on the relationship.
• Delete this record also Available only if a custom object contains the lookup relationship, not if it’s contained by a standard object. However, the lookup object can be either standard or custom. Choose when the lookup field and its associated record are tightly coupled and you want to completely delete related data.
  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 are not available for lookup relationships to business hours, community, lead, price book, product, or user 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. Once B is deleted, the relationship between A and B no longer exists and C will hold an empty value for the lookup.

In a multilevel lookup relationship, these options might conflict. For example, in the scenario where field A is the target lookup of field B, which in turn is the target lookup of field C, you might specify that A can delete B, but B cannot be deleted because it’s in a relationship with C. If you try to delete A, you’ll get an error saying 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 does not record the deletion. For example, if a parent account is deleted, the Account History related list for the child account does not show the deletion.

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 may 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 only:
  • Indirect lookup relationship fields don’t display the expected names of parent records. Instead, each indirect lookup 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 field is created.
  • External lookup relationship fields don’t always display the expected names of parent records. If your org has previously retrieved the parent record, the external lookup relationship field displays the name as expected. Otherwise, the external lookup field displays either the parent object ID or the value of the parent object’s External ID standard field. The latter appears by default. If, however, a custom field on the parent object has the Is Name Fieldattribute, the parent object ID is displayed. If you see an ID in an external lookup 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 Uniqueattributes 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 are 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 report types are:

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

The reporting impact of each relationship type is summarized in the following 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 as well as master-detail relationships.

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.