{"id":"meta_deploy_deleting_files","title":"Deleting Components from an Organization","content":"

Deleting Components from an Organization

\n
To delete components, perform a deployment with the deploy() call by using a destructive changes manifest file that lists the\n components to remove from your organization. You can perform a deployment that only deletes\n components, or a deployment that deletes and adds components. In API version 33.0 and later,\n you can specify components to delete before and after other components are added or updated.\n In earlier API versions, if deletions and additions are specified for the same deployment,\n the deploy() call performs the deletions\n first.
\n\n
\n

Deleting Components in a Deployment

\n\n \n

To delete components, use the same procedure as with deploying\n components, but also include a delete manifest file that’s named\n destructiveChanges.xml and list the components to delete in\n this manifest. The format of this manifest is the same as\n package.xml except that wildcards aren’t supported.

\n\n
\n\"Note\"
\n

Note

\n

You can’t use destructiveChanges.xml to delete items that are\n associated with an active Lightning page, such as a custom object, a component on\n the page, or the page itself. First, you must remove the page's action override by\n deactivating it in the Lightning App Builder.

\n
\n
\n\n

The following sample\n destructiveChanges.xml file names a single custom object to\n be deleted:

\n\n 
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Package xmlns=\"http://soap.sforce.com/2006/04/metadata\">\n    <types>\n        <members>MyCustomObject__c</members>\n        <name>CustomObject</name>\n    </types>\n</Package>
\n\n

To deploy the destructive changes, you must also have a\n package.xml file that lists no components to deploy,\n includes the API version, and is in the same directory as\n destructiveChanges.xml:

\n\n 
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Package xmlns=\"http://soap.sforce.com/2006/04/metadata\">\n    <version>68.0</version>\n</Package>
\n\n
\n
\n\"Note\"
\n

Note

\n

\n

    \n
  • To bypass the Recycle Bin, set the purgeOnDelete option to true.
    • \n\n
  • When you delete a roll-up summary field using Metadata API, the field isn't\n saved in the Recycle Bin. The field is purged even if you don’t set the\n purgeOnDelete deployment option to\n true.
    • \n\n
  • If you try to delete some components that don’t exist in the organization,\n the rest of the deletions are still attempted.
    • \n\n
\n\n

\n
\n
\n
\n\n
\n\n
\n

Adding and Deleting Components in a\n Single Deployment

\n

You can perform a deployment that specifies components\n to delete in destructiveChanges.xml and components to add or\n update in package.xml. The process is the same as with\n performing a delete-only deployment except that package.xml\n contains the components to add or update.

\n

By default, deletions are processed\n before component additions. In API version 33.0 and later, you can specify\n components to be deleted before and after component additions. The process is the\n same as with performing a delete-only deployment except that the name of the\n deletion manifest file is different.

\n\n

The ability to specify when deletions are processed is\n useful when you’re deleting components with dependencies. For example, if a custom\n object is referenced in an Apex class, you can’t delete it unless you modify the\n Apex class first to remove the dependency on the custom object. In this example, you\n can perform a single deployment that updates the Apex class to clear the dependency\n and then deletes the custom object by using\n destructiveChangesPost.xml. The following are samples of\n the package.xml and\n destructiveChangesPost.xml manifests that would be used in\n this example.

\n

Sample\n package.xml, which specifies the class to\n update:

\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Package xmlns=\"http://soap.sforce.com/2006/04/metadata\">\n    <types>\n        <members>SampleClass</members>\n        <name>ApexClass</name>\n    </types>\n    <version>68.0</version>\n</Package>
\n

Sample\n destructiveChangesPost.xml, which specifies the custom\n object to delete after the class\n update:

\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Package xmlns=\"http://soap.sforce.com/2006/04/metadata\">\n    <types>\n        <members>MyCustomObject__c</members>\n        <name>CustomObject</name>\n    </types>\n</Package>
\n

Post destructive changes are processed before running\n any tests.

\n

When deleting Apex classes or triggers, Salesforce recommends that\n as part of the deployment, you run all local tests from the namespace in order to\n detect any remaining references to the deleted class or trigger.

\n
\n
\n\"Note\"
\n

Note

\n

The API version that the deployment uses is the API\n version that’s specified in package.xml.

\n
\n
\n
\n
\n\n
\n
\n
"}