5

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:

  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 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.

Cross post from Salesforce Developer Forum

Improve this question
2
  • Can you provide more background about "I then have a formula field that sets a boolean to true if today is between Open and Closed"? Are you using Workflow, ProcessBuilder, Trigger or what? A pure formula can't update other fields
    – Uwe Heim
    Commented Oct 6, 2017 at 12:12
  • Sorry @UweHeim it's been over two years since I posted this question. At a guess I'd say it was a regular formula field and my wording was clumsy. It should have been "I then have a formula field whose boolean value is True if today is between Open and Closed"
    – powlo
    Commented Oct 6, 2017 at 13:38

1 Answer 1

Reset to default
3
+50

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 destructiveChangesPre.xml and destructiveChangesPost.xml to split the dependencies as required.

Consider voting for the idea: destructiveChanges should delete dependencies if all components are included

Improve this answer
8
  • But even when you explicitly list 2 fields where one has a dependency on the other, it will throw an error saying that the "child" field has a dependency on the "parent". The only workaround I found was to list the "parents" in a separate destructiveChanges list and delete it first
    – brezotom
    Commented Oct 9, 2017 at 2:06
  • @brezotom I believe you can now use the destructiveChangesPre.xml and destructiveChangesPost.xml manifests that were introduced in the Spring '15 release (v33.0). This would allow you to split the dependencies into to stages
    – Daniel Ballinger
    Commented Oct 9, 2017 at 19:41
  • 1
    @brezotom True, it still puts the onus on you to identify and split off the dependency. Still, at least you can do it all in a single deploy. You could raise an idea to see if Salesforce will simplify the process.
    – Daniel Ballinger
    Commented Oct 9, 2017 at 21:58
  • 1
    success.salesforce.com/ideaView?id=0873A0000003Vl2QAE
    – brezotom
    Commented Oct 10, 2017 at 11:59
  • 1
    @powlo I've included the idea that brezotom created that would remove the pre/post split requirement. At this stage I think it is best we can do.
    – Daniel Ballinger
    Commented Oct 10, 2017 at 19:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .