How To Convert Lookup To Master-Detail?

This blog is mainly focused on how to convert a lookup relationship into master - detail relationship. In multiple business use cases we need to convert the lookup relationship into master-detail relationship.

Consider joining a professional online Salesforce admin training if you are looking to succeed as a Salesforce professional!

Relationship Limits

Each custom object can have up to two master-detail relationships and many (40) lookup relationships. Each relationship is included in the maximum number of custom fields allowed.

For detail understanding about the fields and basics you can refer Become a Salesforce Admin.

Prerequisite and Consideration

You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value. Otherwise you will get the below error.

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.

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

Also you should have Allow reparenting check box checked for that field otherwise you will find master detail disabled when you try to change the data tyoe to master detail.

Steps to Covert

Generally Salesforce Administrator will create and convert these stuffs,  For more information Salesforce admin role and responsibilities 

1. Open the lookup field

2. Click on edit button

3. Click on change field type button

4. Click on Master-Detail relationship checkbox

5. Click on Next , Next (for profile and Layout) and Save

Best Practice

If you so choose to still embark on this converting journey, I would suggest that you conduct a complete backup of your system and to thoroughly test in your sandbox or a developer org with sample data.

It is important to do a complete backup as your objects may create a large web of relationships and interdependencies. It is best to be safe and have all of your data just in case.

For better testing considerations, you will need to test the following things in your Sandbox:

1. Configurations: There can be so much going on behind the scene in our Salesforce instances that we really need to be testing to be sure that we aren’t going to break any integrations or set off any Apex Triggers into hissy fits.

2. Data Quality and Security: The Record Owner will be affected as well the Security settings. Even though you are armed with this knowledge, you will want to test in your Sandbox with data to make sure that you aren’t going to regret the changes if made in your Production environment. Test all your data which is used in the associating the child record to parent one.

3. Reports and Dashboards: As I laid out above, these can be gravely affected by the relationship change. Please do push some data to your Sandbox and check them before and after you make the conversion in order to see whether or not your Reports and Dashboards are going to maintain their health.

In case you don’t have licenses to the sandbox - No need to worry! You can easily create a package that includes your custom objects and reports, upload that privately, and then download it into a separate, free, developer org.

Quick Refresher on Master Detail and Lookup 

Salesforce Training For Administrators & Developers

• No cost for a Demo Class
• Industry Expert as your Trainer
• Available as per your schedule
• Customer Support Available

Enroll for Demo Class

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

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 checked 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 the following 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.

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:- 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 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 aren’t available for lookup relationships to business hours, network, 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. 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.

If you think the challenging role of Salesforce administrator excites you, refer Salesforce admin tutorial to learn more about this job role.