Learn how to simplify the process of performing destructive changes in Salesforce, making it easier and safer to remove unused Apex Classes and other metadata types automatically.
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:
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.
Unfortunately, Salesforce does not make it very easy to remove code. Destructive changes in Salesforce are just a pain.
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.
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.
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.
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.
What are destructive changes in Salesforce?
Why is it important to remove unused code in Salesforce?
Why is it challenging to make destructive changes in Salesforce?
What is the role of Blue Canvas in making destructive changes in Salesforce?
What is the risk associated with deleting fields through a destructiveChanges.xml script in Salesforce?
How does Blue Canvas provide a safety net for making destructive changes?
How can I start making destructive changes with Blue Canvas?
How Sysco's team of 40+ developers and admins support a complex Salesforce release flow with Blue Canvas.
Our latest feature offers proactive suggestions so you can avoid dependency errors and better understand relationships between your Salesforce objects.
From your sandbox to a git repository in less than a minute
Why Salesforce DevOps is more than just hooking up a git repo to a Salesforce org
Diving into what it takes to smoothly merge work across Salesforce orgs