Why and How we need to remove retired functionalities from a Salesforce Org

 Salesforce Orgs -  which are existing for more than 5 years, it is very common that some functionalities become obsolete after a certain period of time. Let us see why and how we need to remove these retired functionalities and related components. 

Why we need to Remove retired functionalities 

1. Better Salesforce Governor Limits

Like you know, Salesforce is having many limits with respect to the number of fields, the number of objects, code storage, validation rules, formula fields, etc. per Org. When we remove/delete unwanted components from an Org, it gives us additional space for new functionalities

2. Improve Performance 

There might be associated back end logic which is still getting executed on a record save, even if that feature is not in use. It will consume execution time, SOQL/DML limits of your current transaction. So removing this logic will help with better transaction performance

3. Avoid Unexpected Exceptions

Obsolete backend functionalities can cause unexpected transaction behavior and you will end up in spending time to resolve this unnecessarily

4. Improve Code coverage

Removal of unwanted functionalities are going to improve the code coverage a lot.

5. Help with Classic to Lightning Migration

Custom functionalities which are existing in the system for more than 5 years, might be built using visualforce, more javascript functions and even using S-controls. So definitely when we do Classic to Lightning migration, the effort is going to be affected by existing obsolete features. So as a best practice, better to remove these retired functionalities before we do  lightning transition analysis/implementation

6. Help with SalesforceDX Transition

One of the main features of SalesforceDX is the utilization of Scratch org to develop your functionality, and you need to do a logical packaging of your components for this. Scratch org is having limits on components that can be pulled to your org for development on top of existing functionalities. And this limit range is much low compared to a sandbox. There are high chances that you will hit the org limit when you want to work on the enhancement of complex functionality. 

So removal of unwanted components will help with better DX transition and implementation.

Steps Involved with Removing Retired functionalities

Let us see the activities involved in Each of these Steps:

1. Analysis

Once we identify the functionalities that need to be removed, it is important to get the business stakeholder's approval for removing. 

Once we have the approval, it is the development team's responsibility to identify all the related components, that need to be removed. But how to identify dependent components?  

Approach 1 - Try deleting the component 

The traditional approach is that when you try to delete a component it will show all the related components. Let us see an example here.

I have a country object which is not getting used nowadays. So I would like to delete that object. 

The normal practice is that we will try to delete this in a sandbox, and see if there is an error.

Let us try to delete:

Result

This clearly says that this object is getting referenced in a process builder. On our analysis, we found that this process builder can also be deleted. So let us delete the process builder and try to delete the object again.

Result

Again deletion failed because it shows the next dependency, a lookup field in contact object. So this way we can identify related components and decide if we need to delete that component or just remove the reference.

Problem with this approach

Like you can see, the problem with this approach is that it might not give us all dependency on a single delete operation. For complex implementations, this approach is time-consuming.

Approach 2 - Dependency API

This is still in the Beta version, so we cannot completely guarantee that this will give us all dependencies. 

But we can use query or REST API to find out related components using Dependency API. Please find a screenshot below:

I have used below request to find out dependency of Country Object:

/services/data/v48.0/tooling/query?q=SELECT+MetadataComponentNamespace,+MetadataComponentId,+MetadataComponentType,+MetadataComponentName,+RefMetadataComponentNamespace,+RefMetadataComponentType,+RefMetadataComponentName,+RefMetadataComponentId++FROM+MetadataComponentDependency+WHERE+RefMetadataComponentId+=+'01I2x000000VwF7'

Result

This approach will be faster compared to the previous one.

So using either of this approach you can find out all dependent components.

2. Align with Interlocks if any

Once all components are identified, reach out to your interlock systems to see if they are utilizing any of these components. If there is no dependency, we can plan for components removal based on our release schedule. 

3. Implement in Full copy Sandbox

If the external system has references, we should follow the below steps:

1. Removal of reference to our components by External systems

2. Once they confirm removal, we can remove profile level permissions to all these components

Instead of directly deleting this, the above approach is better, since if we identify some issues we can rectify quickly.

If external systems do not have a reference, we can directly remove access to profiles/permission sets.

4. Regression Testing

After access removal, we need to do a regression Testing of existing functionalities to make sure that nothing is breaking. This can be executed in 2 approaches:

1. Execute Regression testing scripts if you the scripts already

2. If we do not have regression testing scripts, we need more manual effort to test major functionalities to make sure that nothing is breaking. 

5. Soft Launch

Once regression testing is a success, we can deploy access removal to production as part of the next release cycle.

6. Monitoring

Next is the monitoring period. Based on the functionality complexity, you can decide on the monitoring period. If you are not hearing any issues till the next release, which is at least in a gap of 3-6 months, we can plan for hard delete.

7. Complete Removal of components

Once there is no issue from the soft delete, we need to plan for final deletion activities. It basically involves the below steps:

1. Plan for Data backup

Your company might already has a data back up approach and use that and take a backup of all data related to component removal.

2. Plan for metadata backup

If your org is following DevOps practices, you might have already metadata backup. But it is also good to take a separate backup of only these components and store to your repository

3. Prepare destructiveChanges.xml

Since deletions are taking place using destructiveChanges.xml, prepare this file with components that needs to be deleted. And follow the deployment approach that your organization is following.

4. Execute this against a Full copy sandbox and do Regression

Similar to what we have done during  profile access removal, we need to do regression here also after removing components

5. Deploy to production

Once all good, we can remove components from production using destructiveChanges.xml

I hope this was helpful for you to understand, steps to be followed to remove retired functionalities from your Salesforce Org. And this should be an ongoing activity for your Org to improve performance.