6

I'm trying to delete all of the worflow rules & triggered tasks associated with a custom object, using the Force.com Migration Tool, but I keep getting errors.

First I tried to submit blank workflow metadata use the following destructiveChanges.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>Custom_Object__c</members>
    <name>Workflow</name>
  </types>
  <version>26.0</version>
</Package>

...but I get this error:

BUILD FAILED
C:\Users\...\build.xml:69: FAILURES:
Error: workflows/Custom_Object__c.workflow(Custom_Object__c):Cannot delete a workflow 
object; Workflow Rules and Actions must be deleted individually

But when I tried to list the indivual rules and actions in the <members> lists, I got an error that those workflow components couldn't be found.

How can I delete these? I'm trying to avoid having to go into each workflow rule, deactivate it, then deleting the field updates, and finally deleting the workflow rules.

1
  • Have you tried using the WorkflowRule component type, i believe the member name would Custom_Object__c.MyRule. There is also a WorkflowTask component type. Commented Nov 26, 2012 at 18:13

1 Answer 1

8

Workflow Rules have their own component type, as do Workflow Tasks, try this...

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>Custom_Object__c.MyRule</members>
    <name>WorkflowRule</name>
  </types>
  <version>26.0</version>
</Package>

You may have to do this for WorkflowTask's as well.

Follow up question via comment below...

The WorkflowRule and WorkflowTask appear in the package folder structure as follows. They basically use the /workflows folder and the .workflow file extension. You can read more about them in the Metadata API developers guide here.

enter image description here

enter image description here

P.S. If your interested in the above code it is here.

3
  • What folder of my deployment directory would I put the relevant files (if it were a deployment -- source code obviously not needed for destructive changes)
    – Benj
    Commented Nov 27, 2012 at 1:54
  • I've updated my answer to clarify this. Commented Nov 28, 2012 at 9:00
  • Got it, so it works similarly to custom fields, which can be listed discretely but are still included in the same metadata object. Really helpful, thanks!
    – Benj
    Commented Nov 28, 2012 at 15:42

You must log in to answer this question.

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