[SalesForce] Retrieve and Deploy a workflow using ANT

I am working on some customization for a CPQ product and I have created a workflow to populate some of the fields. I would like to deploy this workflow from the developer sandbox to our fullcopy sandbox using ANT. However, I am not seeing any example on how to retrieve and deploy a workflow using the ANT migration tool. The force.com migration tool guide says that workflow is a container which contains several elements like WorkflowTask, WorkflowRule etc, but no example.

Can some one help?

Best Answer

For adding things to a package.xml file, you need two pieces of information:

  1. The metadata type name
  2. The fully qualified name of the thing you're trying to retrieve/deploy

For finding the metadata type name, I find the metadata api types documentation to be a good resource.

The metadata type name is exactly what you use in between <name></name> in your package.xml file, and I believe it works for everything except the metadata types listed in unsupported metadata types. In this case, if you want to deploy an entire workflow, the metadata type name that you'd use is Workflow

Although the documentation only provides one example (which is rather unfortunate, I think), the general format that you'll use for including a workflow in a package.xml file is documented on the documentation for the Workflow metadata type

<types> <members>*</members> <name>Workflow</name> </types>

Finding the fully qualified name is a bit trickier. For some metadata items, like Apex Classes, it's simply the name of the thing you want to deploy. For others, like fields or validation rules on an object, you use the object name as a prefix. In rarer cases, like email templates and reports which can be organized into folders, you need to use the folder names and forward slashes much like you'd do if you were typing a url.

For workflow, the fully qualified name is the API name of the object the workflow is for. Adding this to a package.xml file would look like this:

<types>
    <members>Opportunity</members>
    <members>My_Custom_Object__c</members>
    <name>Workflow</name>
</types>

To me, this makes sense because the current structure of Salesforce's metadata includes workflow as part of the metadata for CustomObject (which contrary to its name encompasses both standard and custom sObjects). If you dive into the metadata that gets retrieved when you retrieve nothing but workflows, you'll notice that the folder structure you get is

working directory -> package name-> Objects > (list of objects that you're retrieving workflow for)

instead of

working directory -> package name -> Workflow -> (list of workflow that you're retrieving)

+edit: after taking a second look, I don't believe the above is true for Workflow, it is true for other things like ValidationRule though. Workflow is tied to an sObject though, so using it as the fully qualified name still makes sense to me here.

As the documentation notes, the Workflow metadata type itself can contain other metadata types, and you can use these to deploy individual workflow rules (WorkflowRule), email alerts (WorkflowAlert), field updates (WorkflowFieldUpdate), etc...

The fully qualified name for individual parts of a workflow use the API name of the object the overall workflow is on, a dot (period/full-stop), and the API name of the workflow component that you want to retrieve/deploy.

An example is:

<types>
    <members>Opportunity.Update_Field_On_Condition</members>
    <name>WorkflowRule</name>
</types>
<types>
    <members>Opportunity.My_Workflow_Field_Update</members>
    <name>WorkflowFieldUpdate</name>
</types>

It should be noted that you may run into issues deploying individual parts of a workflow rule, because the order in which things does matter (the workflow needs to exist before you can add/change/remove rules, field updates etc...)

Related Topic