Recently, a client asked us to change a relationship from Master Detail to Lookup in their Salesforce environment. They did not want that field to be required to create a record, because the user didn’t always have the information at the time of data entry. As a result, the requirement created issues with data integrity as well as causing frustration.
This change was important to our client, but took more than pushing the Change Data Type button while editing a custom field. Making the change in Salesforce meant planning, precautions and a series of steps on our part. We wanted to share some tips and best practices that we learned.
Don’t Count on Change Data Type
If there are any rollup fields, you won’t see the Change Data Type button when you edit the field. This makes sense since rollup fields cannot be created when there is no Master Detail relationship present. Also, you may not see this button if you have any other dependencies on the Master Detail Relationship field. We had no rollup fields, but could not simply use the Change Data Type button to make the change.
After a data backup, we tried deleting the field to send it to the Recycle Bin where it could be recovered. Once recovered, it would be restored as a Lookup relationship and the data would be recovered when the field is restored.
Deleting a Column with Dependencies
Of course, you can’t delete a column if it has dependencies, and clearing them raises issues.
1. Deactivating workflows did not clear dependency on the Workflow. We had to delete the workflows along with any field update actions as well
2. Code Dependencies: Any code that may reference the column has to be handled. This was a major headache for our developer as he had to hunt down and correct code dependencies and failed test scripts.
3. The dependent columns must be completely deleted. They cannot remain in the deleted fields list on the object. We had a few related formula fields that used the column in question. Rather than delete these, we copied the formula text to a document and replaced the formula with a hardcoded value
4. Process Builder processes need to be deleted as well. Again, deactivating them will not clear the dependency. When we performed this change, we had to wait 12 hours after deactivating. Thankfully, Salesforce removed this required wait time in the Summer ’15 release. However, if there are any pending actions from the process, you must either complete or delete them before you can delete the process.
5. Relationship changes will affect any reports dependent on that column. You will not be able to edit or run the report after the relationship is changed. This does not show up on the list of dependencies but we encountered this after everything was back in place.
Restoring the Deleted Fields
Once the dependencies were all addressed, we could delete the column and restore it. The good thing is that none of the data was lost, so restoring the data from our backup was not necessary.
Figure 1 - System Dialog after restoring a deleted field.
We returned the formula code to the dependent formula columns, but the formulas would not save due to errors referencing the column. Since the field is returned with a “del” in the name to identify it as a deleted column, you should rename the field as soon as it is restored. Once the column is restored to its pre–deleted form, you can restore all the objects you had to delete or modify to clear the dependency.
The screenshot shows other changes to address once the column is restored. If you want the lookup to be required, make sure you set the column as required. Also, restore the column back to the page layouts.
Test and Test Again
Keep a running list of the dependencies, how you addressed each one, and how you tested it to confirm that it was corrected. In addition, be sure to test once everything is pushed to production.
It’s not a very difficult process to follow, but beware of the dependencies and plan accordingly. There may be other issues that we were fortunate to avoid, so be on the lookout.
