Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
PaulBackhousePaulBackhouse 

Destroying a formula field via Ant Migration Tool

Hi,

I a very simple case that I'm surprised Salessforce 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  Itry and destroy these changes (rename package.xml to destructiveChanges.xml, create empty package.xml) I get the following error:

1.  objects/Account.object (Account.Open_Date__c) -- Error: This custom field is
 referenced elsewhere in salesforce.com. : Custom Formula Field - Account.Active
__c.

But my destructiveChanges should destroy all fields incluved, 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 selft contained.
Sagar PareekSagar Pareek
You are trying to delete Account.Open_Date__c ,which is not possible to be deleted if it is being referenced in your formula field. Try deleting formula field first and then Account.Open_Date__c. 

The error you are facing is same error when you go and delete any field from Salesforce UI , if that field have any dependency it shows similar error. - So this is default behaviour. 
PaulBackhousePaulBackhouse
@Sagar Well that's not quite true. When I deploy a destructive changes file I'm deleting many obects simultaneously.
Daniel BallingerDaniel Ballinger
Cross posting answer from same question on the SFSE (https://salesforce.stackexchange.com/a/194893/102).
 
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.