Converting Lookups to Master-Detail Relationships

There are many reasons as to why you may want to convert a Lookup to a Master-Detail Relationship. You may need to roll-up data, simplify security settings, or maybe you had initially meant to create a Master-Detail but instead created Lookup and are now just getting around to making the change.

When embarking on such a change, there are several considerations that must receive attention. Salesforce doesn’t do a great job at documenting it but there are many things that can be affected by converting a lookup relationship to a Master-Detail one. This article aims to compile the information for you so that you can avoid those seemingly life-threatening risks associated with making such a change. It finishes with a few helpful Recommendations and Best Practices.

Gotchas

To start, let’s go over the better-known gotchas with converting a Lookup field to a Master-Detail Relationship.

1. The Current Lookup Field:
The current Lookup field on the Child object must be populated in every single record. If there are records without this field populated, the conversion will not occur.

2. Record Owners and Security:
The Child record will inherit the Record Owner of the Master record. Additionally, the Child record will inherit all of the security settings of the Master record.

3. Reports:
This is where it gets tricky. Salesforce offers the following information:

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

While this is helpful, it still leaves out some key pieces of information and is thus not entirely true. Below, I show some screenshots of the destiny of a report on the object in question. As you will see, the report is not completely restored to its original form after reverting the changed relationship.

Pre-conversion

I created a summary report with the Order and Order Line Item Owner as the groupings on the report.

Post-conversion

After converting the Lookup to a Master-Detail Relationship, I received the above error message when trying to view the report.

Post-reversion of relationship

This is where Salesforce misses key points. Even after reverting the relationship, the Order summary grouping has been stripped from the report.

Implications?

If you have any Dashboards that happen to work off of this Report, they will not function as Dashboards cannot use Summary Reports that do not have any groupings. So if this was your only grouping on the report, you would see the following error on your dashboard.

While these changes can be “fixed” with lots of time and energy, it may just be easier to keep it as a lookup or perhaps write a Trigger that rolls up any data needed on the Parent record.

Recommendations and Best Practices

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.

In regards to testing, you will need to test the following things in your Sandbox:
1. Infrastructure: 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 health and Security: As I mentioned above, the Record Owner will be affected as will 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.

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.

Don’t have a Sandbox? No need to fret! 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.