Destructive Changes in Salesforce

In this article, we'll guide you through the process of performing destructive changes in Salesforce with the help of Blue Canvas, shedding light on the challenges of removing unnecessary code and how to overcome them. You'll learn how Blue Canvas enables the automatic generation and deployment of destructive changes, and the safety net it provides in terms of code backup.

Here are our 5 key takeaways:

Many Salesforce organizations have accumulated unused code over the years, which can affect both application performance and developer workflow speed.
Regularly removing unused code is beneficial but can be challenging due to Salesforce's limitations on making destructive changes.
Tools like Ant and XML scripting can be used for removing code, but they require specific domain knowledge and are not always reliable.
Deleting fields through a destructiveChanges.xml script is irreversible, which can make the process risky and lead to hesitation in removing old code due to potential dependency issues.
Utilizing tools that track all changes and provide backups for everything deleted can boost confidence in cleaning up old fields and types, ensuring a safety net in case of regrettable deletions 👌

The Need for Destructive Changes in Salesforce

Are there fields or metadata components in your Salesforce orgs that you no longer need? Is all of your code being used by your end-users? For many the answer is “probably not”. After years on the Salesforce platform, many organizations have seen the build up of unused code on their Salesforce orgs and are working to clean things up. Having unused code in your application is a real cost from a performance and developer workflow perspective. Unused code will slow you down in both the speed of your application and the speed of your developers in their ability to improve the application. Regularly cleaning up unused code is a good thing to do.

The Challenges in Implementing Destructive Changes

Unfortunately, Salesforce does not make it very easy to remove code. Destructive changes in Salesforce are just a pain.

The Limitations of Salesforce

You can’t make destructive changes with Change Sets. You have to use the Force.com migration tool. That requires some specific domain knowledge and the setup and maintenance costs associated with running the Ant migration tool. And even if you are an expert with Ant and XML scripting, the tool isn’t always reliable for destructive changes.

Introducing Blue Canvas for Destructive Changes

Blue Canvas allows you to do destructive changes easily. Simply compare to branches. Items that are red will be deleted.

Blue Canvas then generates the destructiveChanges.xml and deploys the destructive change automatically.

The Risks of Deleting Fields in Salesforce

Generally, when you run a destructiveChanges.xml script and delete fields, you cannot undo what you have done. Deletions are permanent. This can make deleting fields a bit scary and it’s a big part of why teams are so hesitant to do it. And this is why we see so many massive Salesforce projects with code from 8 or 9 years ago that no one is willing to delete because they don’t have the confidence to know that what they are deleting won’t cause dependency issues with their more recent code.

How Blue Canvas Provides a Safety Net for Destructive Changes

With Blue Canvas all changes are automatically version controlled, nothing is permanently deleted. You always have a backup of everything that you add, modify or delete in you Salesforce orgs. This gives you the confidence to delete old fields and types without worrying about never being able to restore them again.

‍

--------

FAQs

What are destructive changes in Salesforce?

Destructive changes in Salesforce involve removing unused code such as Apex Classes and other metadata types that are no longer needed. This is typically done to improve application performance and developer workflow speed.

Why is it important to remove unused code in Salesforce?

Unused code can slow down both the speed of your application and the speed of developers' ability to improve the application. Regularly removing unused code improves application performance and developer workflow speed.

Why is it challenging to make destructive changes in Salesforce?

Salesforce does not provide an easy way to make destructive changes. This process often requires specific domain knowledge, such as using tools like the Force.com migration tool, Ant, and XML scripting, which can be complex and are not always reliable.

What is the role of Blue Canvas in making destructive changes in Salesforce?

Blue Canvas simplifies the process of making destructive changes in Salesforce. It enables easy comparison between branches, marking items to be deleted in red. It then automatically generates the destructiveChanges.xml and deploys the destructive changes.

What is the risk associated with deleting fields through a destructiveChanges.xml script in Salesforce?

Deleting fields through a destructiveChanges.xml script is irreversible. This makes the process risky as it can potentially lead to issues due to dependencies with more recent code.

How does Blue Canvas provide a safety net for making destructive changes?

Blue Canvas tracks all changes in Git, ensuring nothing is permanently deleted. It provides a backup for everything that is deleted in Salesforce orgs, giving users the confidence to delete old fields and types without worrying about restoration issues.

How can I start making destructive changes with Blue Canvas?

You can start by using Blue Canvas to compare branches and mark items to be deleted. Blue Canvas will then automatically handle the rest by generating and deploying the destructive changes.

Table of Contents