I have a very simple case that I’m surprised Salesforce migration tool can’t deal with.
I have two date fields on Account: Open and Closed.
I then have a formula field that sets a boolean to true if today is between Open and Closed.
These are stored in an unmanaged package.
So far so good. But when I try and destroy these changes (rename package.xml to destructiveChanges.xml, create empty package.xml) I get the following error:
- objects/Account.object (Account.Open_Date__c) — Error: This custom field is
referenced elsewhere in salesforce.com. : Custom Formula Field – Account.Active
But my destructiveChanges should destroy all fields included, the date fields and related formula.
Do I have to bash out staged destructions, ie figure out which fields are formula fields, destroy those, then destroy other fields? These seems horrible and I was hoping the tool would be smart enough to recognise that the destruction is self contained.
My understating is that you always need to be explicit on what is included in the destructive change.
While inconvenient that you need to list out every component to be deleted it is a good safety feature.
Imagine you test it out in a sandbox and it implicitly deleted all the dependent components from those fields. You knew there was only a formula field that would be deleted in addition to the fields, so that was fine.
However, you then do the same against production, and it implicitly deletes additional workflows and triggers that also depended on those fields but weren’t yet present in your sandbox org as another admin or developer created them independently. Guess who won’t be a popular person when that happens!
So, yes it’s inconvenient to have to explicitly delete the dependencies, but it is much safer in the long run for something that can have large and irreversible affects.
With regards to problems with explicitly deleting dependencies in a single metadata api call. See the Spring ’15 (v33.0) feature: Delete Components before and after Component Updates: (my emphasis)
You can control when components are deleted in a deployment. Use a manifest to specify component deletions before updates, and use another manifest to specify component deletions after updates. Specifying the processing order of deletions relative to component updates provides you with greater flexibility and enables you to delete components with dependencies.
You can use a
destructiveChangesPost.xml to split the dependencies as required.
Consider voting for the idea: destructiveChanges should delete dependencies if all components are included