Salesforce makes it easy for you to add fields, objects and customizations. Salesforce teams don’t always anticipate the problem of redundant metadata, which can quickly clutter up your org as processes evolve and plans change. Obsolete features in your org are a problem, and the solution must be carefully chosen. In this post we’ll explore the reasons for deleting metadata, and how to do it safely.
Redundant metadata needs deleting
Over time, orgs will undoubtedly gather fields, objects and other items lying around that are no longer needed. For example, a team member could have created some fields while building a new feature a few years ago, which weren’t deleted even though they were never used. The use of custom features in Salesforce by end users invariably changes over time, meaning that customizations you built a while back are now no longer needed.
But why does this matter? Cluttered and bloated Salesforce orgs that contain lots of redundant metadata slow everything down and could cause issues for your end users. It’s therefore important to clean up your Salesforce org by getting into the healthy habit of deleting redundant metadata on a regular basis. But this can, of course, be a scary prospect for many because deleting things feels final:
Soft delete vs hard delete of Salesforce records
The data deletion process through Salesforce first starts with soft deletion, which essentially moves the data into a Recycle Bin. Although it might be straightforward to move data to the Recycle Bin and just forget about it, it’s important to realize that doing so doesn’t actually delete the data - it just removes it from your sight. The data still exists and therefore still affects the performance of your Salesforce org.
After 15 days, or when the Recycle Bin reaches a certain size, the data is hard deleted, meaning the data is fully removed from your org. It’s also possible to directly hard delete data and bypass the soft deletion using the Bulk API - but hard deletion is risky as you won’t always know what the consequences are.
It’s easy to fall into the trap of deleting data from your org and thinking your job is done. The metadata still needs to be deleted, though, and that’s when you need the right solution.
Deleting objects and fields requires the right tools
Not all deployment tools allow for destructive changes. Change sets in particular don’t offer any support for deletions and can only be used to add metadata to your orgs. It’s possible to delete objects and fields with the ANT migration tool using a
destructiveChanges.xml file, but that process is difficult to master and can be a huge headache.
As well as being difficult, making deletions with ANT isn’t a safe option. Making destructive changes can be dangerous, and it can take up a lot of time to figure out if the components you’re deleting will break something. The only way to be sure you can safely delete something is having something to fall back on if everything goes wrong. In other words, it’s important to have the ability to roll back after deletions.
Make destructive changes safely and easily with Gearset
With Gearset, making destructive changes is as simple as everything else. Our aim is for your Salesforce workflow to be as smooth as it should be - and deletions are no exception to that. Deleting objects will fit effortlessly into your workflow, and can be managed at the same time as your new and modified objects.
After running a comparison between two orgs in Gearset, you will be presented with the familiar comparison view. Switch to the Deleted items tab to see a line-by-line comparison display of which objects are present in your target org but not in your source.
Select the objects you want to delete by checking the relevant boxes, and they will be gone once you deploy! Of course, as with any deployment, you’ll be able to roll back afterwards if you want to undo those changes.
The process of deleting components through Gearset is both easy and safe. To benefit from orgs free of bloat, you can start clearing out unnecessary metadata using your familiar deployment workflow. Not only that, you’ll automatically get the Gearset safety net in the form of rollbacks at the click of a button!
Technical debt builds up when you take shortcuts in your development processes to speed up delivery. Attempting to accelerate the delivery of a functionality or feature has the short-term benefit of a faster time to market, but in the process you’ll incur a little debt. In the Salesforce world, one of the types of technical debt is redundant cruft in your orgs, like unused packages and half-finished validation rules.
Sometimes technical debt is unavoidable. For example, there’s a payoff between releasing code that’s good enough and does the job to allow for quicker delivery, and code that’s perfectly designed but takes longer to produce. Also, business requirements inevitably change leading to even more outdated metadata.
Other than adopting best practices to avoid collecting technical debt where possible, the most important step to take is to prevent debt from sticking around too long in your orgs. This means identifying cruft early on and removing it. Here, Gearset not only makes it possible for you to deploy destructive changes safely, but also helps you to identify issues with your Apex code. By automating your unit tests and running static code analysis every time you deploy or validate, Gearset lets you check that your team’s new code complies with best practice guidelines around code style, design, security and performance.
Want to include destructive changes in your deployments?
There’s no reason why deleting metadata shouldn’t be as easy as adding it. If you want to have a single smooth workflow to deploy new, modified and deleted objects all at once, along with the peace of mind knowing you can always roll back, use Gearset’s compare and deploy solution. Try it out for yourself with a 30-day free trial.