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 migration tool guide says that workflow is a container which contains several elements like WorkflowTask, WorkflowRule etc, but no example.

    Can some one help?

  • 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:


    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:


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

    Somehow my retrieval of workflow rule like that didnt work. I'm wondering is it because my parameter has space in workflow rule name like "Opportunity.Update Field On Condition"

  • It was not that difficult. All I had to do is to include the below snippet to do a retrieve.


    The above code snippet in the package.xml retrieved all the workflows of the CustomObject under the workflows folder. I did not change anything, but used the same package.xml to do the deploy and it worked. I guess if I have to do a selective deploy on a workflow of a custom object, I can edit the CustomObject.workflow file to get rid of the unwanted workflows and then do the deploy.

    Hopefully this will work. Let me know if it doesn't.

    Removing workflow rules from your object.workflow file (the ones that are unrelated to the current deployment) does not delete them from your org when you deploy - which was something I was wondering. I verified this in my sandbox.

  • Nice info..

    FYI - The WorkflowRule member should be the rule's label not api/developer name. (and in urlEncoded format if any special characters)

    <members>Opportunity.My Custom-Field %28Closed%29%</members>

    Here is some sample apex to help generate the label w/ url encoding:

      string nm = 'My Custom-Field (Closed)';
      system.debug(EncodingUtil.urlEncode(nm, 'UTF-8').Replace('+',' '))


    My Custom-Field %28Closed%29

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM