As you might be aware, it’s not possible to modify Apex code directly in production so doing deletes can be really difficult. In production, Apex classes and triggers cannot be deleted declaratively so there’s a pretty inconvenient process that has to happen to remove them.

Before we can deploy any deletions when need to make sure we deploy updates to any version of code that remove the dependency. I recommend at least commenting it out and then performing the deletion.

There’s a few different ways to delete the classes and triggers from Salesforce:

1. Use Visual Studio Code
2. Use the dated Force.com IDE
3. Use the Force.com Migration Tool (ANT)
4. Workbench

Visual Studio Code (VS Code)

Doing deletions in VS Code is pretty easy and is my preferred way.

To do the delete we need to do the following steps:

1. Find the class or apex trigger we need to remove and update the metadata status to be “Deleted”.
2. Run the sfdx force deploy command with all of the classes/triggers separated by “,” using the terminal.

sfdx force:source:deploy -m ApexClass:SomeClass,ApexClass:SomeOtherClass,ApexTrigger:SomeAwesomeTrigger -l RunLocalTests -u AliasOfTheProject

Force.com IDE

There’s two ways to do it with the Force.com IDE.

The easiest way should be to perform any deletions that you need to accomplishin the Force.com IDE. Once you have made all of the necessary deletions deploy the entire class folder or trigger folder to production. Eclipse should figure out the differences between the two folders.

Other way is to do the following:

1. Use an IDE to create a new project and download all classes from production.
2. In the class or trigger, you want to delete, open the metadata file and change the status of the class to “deleted”.
3. Save to the server (you can do multiple together as long as the deletion order doesn’t matter and do one big save.)

The metadata should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
     <ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
         <apiVersion>51.0</apiVersion>
         <status>Deleted</status>
     </ApexClass>

Force.com Migration Tool (ANT)

The Force.com Migration Tool uses the Apache Ant tool to do deployments (additions, updates, deletes). Additions or updates should be included in the package.xml file and removals need to be done in the destructiveChanges.xml file.

Configuring your username and password needs to be done in the build.properties file

Using the Force.com Migration Tool the delete needs to be deployed using the destructiveChanges.xml. When creating a destructiveChanges.xml (don’t forget the capital C on changes!) using a structure like the below file.

Here’s an example of how to remove a single class

 <?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <name>ApexClass</name>
        <members>AClass</members>
    </types>
    <version>51.0</version>
</Package>

Workbench

If you are infrequently doing deletions or deployments through the Force.com migration tool, Workbench is a better solution. It doesn’t require learning the terminal or learning how to use the ANT. The file structure and files are identical because it is basically running the same process.

Workbench is a web-based set of tools that are designed to allow administrators and developers to easily interact with Salesforce orgs. It can do things like data inserts, updates, deletes, exports, and a lot more. My favourite thing about Workbench though is that I can do deletes easily through it without having to mess around with the Force.com Migration tool.

Workbench can be easily accessed at https://workbench.developerforce.com/login.php

When logging in it’s important to make sure that you use the correct Environment (Production for Developer Orgs and obviously Production orgs). You will need to click the “Allow” button so that you can access.

Before we upload the files to workbench to do the deletions we need to create the files. Don’t worry, creating the files is pretty easy and should only take a few minutes for a dozen or so deletes.

What I like to do is use VSCode to create the two required XML files which are called “package.xml” and “destructiveChanges.xml”. The reason I use VS Code is that it can do syntax formatting and tell me if there’s bad XML before I even try and upload it.

I recommend doing them in a folder in a temporary location like the desktop. My package.xml file is really simple, it looks like this:

We then need to create a destructiveChanges.xml file that contains all of the classes or triggers that we need to remove. For a single class it would look something like this:

Now that we have created our two files, we need to zip them up and make sure that the structure is correct. Inside the zip there should be no folders. If you have done things correctly before you create the zip you should have a file structure that looks like this:

Next we need to select the files at the same time and choose “Send to” -> “Compressed (zipped) folder”.

If you’ve been successful the zip should look exactly like this:

Now we can switch back to workbench. Once inside, we need to click the “migration” menu option and choose “Deploy”

When deploying your changes I highly recommend you check the following settings:

• Rollback on Error
• Single Package
• and Test Level “RunAllTestsInOrg” – there’s always a chance you missed something and these tests have the chance of saving your butt. 🙂

After a little while you should see if it has successfully deployed in workbench or within Salesforce.

Wrapping It Up

In this blog post, we’ve covered how to do deletions of apex classes and apex triggers from a production Salesforce org using Force.com Migration Tool (ANT), Visual Studio Code, Workbench, and even the deprecated Force.com IDE.