Delete Apex Class with Workbench
- December 02, 2022
Apex classes and triggers cannot be deleted from a Salesforce production declaratively, unlike in a sandbox org, because security for Apex in a Salesforce production org is greatly increased. So, how can you delete Apex classes and triggers from a production org without the inconvenience and time-consuming effort of installing, testing and learning how to use these tools properly?
The answer: Use a Notepad text editor and the super lightweight, easy-to-use Workbench suite. Using these tools, deleting Apex classes and triggers from Salesforce production is a breeze. Because Workbench is web-based and text editors are already pre-installed and super easy to use, there’s no need to download, install or test the Force.com IDE or Force.com Migration tool (ANT).
For example, you have a Salesforce production org with two Apex classes that need to be deleted.
To achieve this via Workbench:
- Create a folder on your desktop — in this case, ‘deleteClasses’
- Go to Notepad (or another text editor)
- Copy and paste the following code:
1
2
3
4<!–?xml version=”1.0″ encoding=”UTF-8″?–>
<package xmlns=”http://soap.sforce.com/2006/04/metadata“>
<version>30.0</version>
</package> - Save as the file with ‘package.xml’ and ‘All files (*.*)’
- Create a new file in Notepad (or another text editor) and copy the following code into it:
1
2
3
4
5
6
7
8<?xml version=”1.0″ encoding=”utf-8″?>
<Package xmlns=”http://soap.sforce.com/2006/04/metadata“>
<types>
<members>SomeClass</members>
<name>ApexClass</name>
</types>
<version>30.0</version>
</Package> - Replace SomeClass with the name of the class you wish to delete — if you have two classes to delete simultaneously, simply add another row into the file with the name of the other class, for example:
1
2
3
4
5
6
7
8
9<?xml version=”1.0″ encoding=”utf-8″?>
<Package xmlns=”http://soap.sforce.com/2006/04/metadata“>
<types>
<members>SomeClass</members>
<members>SomeOtherClass</members>
<name>ApexClass</name>
</types>
<version>30.0</version>
</Package> - Save this file name as destructiveChanges.xml (note the capital ‘C’ in ‘changes’) — and make sure the file is saved as ‘All files (*.*)’
(More information on destructive changes can be found here.)
- Open the folder, select both XML files, right-click and select ‘Send To > Compressed Folder’
Keeping the default name of ‘package’ for the folder is fine.
- You’re now setup to deploy the destructiveChanges.xml file to Salesforce; to do this, log in to Workbench with your credentials
NOTE: It’s recommended that you log in to a Sandbox instance before you deploy the file to production.
- Select Migration > Deploy
- Click ‘Browse,’ select the .zip package file, check ‘Rollback on Error’ and ‘Single Package,’ and then select Test Level with ‘RunLocalTests’
(More information on the Test Level can be found here.)
- Select ‘Next’ and you’ll notice that Workbench will display the success or error results once the deployment process is complete
Now there are two files in your folder.
— By Dilsha Khan