Tuesday, December 3, 2013

Deploying Destructive Changes Using Workbench

Sometimes, especially in the case of custom Apex or Visualforce, a Salesforce admin or developer needs to delete components from an org. However, Salesforce's user-friendly change sets feature does not allow admins to propagate component deletions. The only semi-automated alternative to performing these deletions, especially in production orgs, is to leverage the metadata API.

Fortunately, with the availability of Workbench on Developer Force, the steps required for deploying destructive changes (that delete components) are pretty simple:

  1. Create a package.xml file
  2. Create a destructiveChanges.xml file
  3. Bundle the two files together in a .zip file
  4. Deploy the .zip package using Workbench

As you can see from this sample .zip package, the files are fairly simple and straightforward. Multiple types of metadata can be removed with a single package.

The exact steps for deploying using Workbench 29.0.1 are:
  1. Open the migration menu, then click Deploy
  2. Click Browse... and select the .zip package file
  3. Mark the "Rollback On Error" checkbox
  4. Mark the "Single Package" checkbox
  5. Mark the "Run All Tests" checkbox
  6. Click Next
  7. Review the deployment options, then click Deploy

The results, successful or otherwise, will be displayed in Workbench for you to review once the deployment process is complete.


  1. This comment has been removed by the author.

  2. What if we're trying to destroy a trigger and a test class (the object is not, was not ever in production, and trigger/test were produced by Salesforce))?

    Running tests will try to run the existing version of the test (which fails, since standard object "Question" does not exist). Is there any syntax or way to run a destructive package without running tests in Production?

    1. I may be over-simplifying the situation, but shouldn't you be able to just delete the trigger and the test class manually in the Setup UI? Try deleting the test class first, and then the trigger. I don't think you need to use change sets if your code has never reached production.