[SalesForce] Salesforce Flow Metadata list / retrieve

Strange Behaviour.
1. When i perform a list operation on Flow, I get the following response.

 [
      {
         "createdById": "00520000003eLmNAAU",
         "createdByName": "Gunish Rai Chawla",
         "createdDate": "2014-08-11T16:42:47.000Z",
         "fileName": "flows/ProjectProgressFlow.flow",
         "fullName": "ProjectProgressFlow",
         "id": "301200000000ETlAAM",
         "lastModifiedById": "00520000003eLmNAAU",
         "lastModifiedByName": "Gunish Rai Chawla",
         "lastModifiedDate": "2014-08-11T18:43:04.000Z",
         "manageableState": "unmanaged",
         "type": "Flow"
       }
    ]

So Far so Good,

But when I fire a retrieve request using the data from the listResponse.

{
    "name": "Flow",
    "members": [
      "ProjectProgressFlow"
    ]
  },

I get a blank ?

Anyone else seen similar behaviour ?

Best Answer

When retrieving a flow from Salesforce, it seems that you need to specify the version of the flow as well. For some reason, the List Metadata API doesn't show the version number for the active version of the flow. It does show version numbers.

Listing Flows

For example, if I have a Flow called My_Custom_Flow, and I make 3 versions, and don't activate any of them, List Metadata will tell me I have the following:

My_Custom_Flow-1
My_Custom_Flow-2
My_Custom_Flow-3

If I then go ahead and activate version 3 of the flow, List Metadata will now say:

My_Custom_Flow-1
My_Custom_Flow-2
My_Custom_Flow

Deploying and Retrieving Flows

However, the actual API name of version 3 is still My_Custom_Flow-3, so when you go to retrieve it, you will need to call it by that name in your package.xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>My_Custom_Flow-3</members>
        <name>Flow</name>
    </types>
    <version>35.0</version>
</Package>

The same applies for the metadata Deploy API; you should deploy the flow using the full API name (including version number), with the additional caveat that you can only deploy the flow version when that version has not been activated in the org before. So if I wanted to deploy a new copy of My_Custom_Flow to this org (where version 3 is activated), I would need to call the flow My_Custom_Flow-4.flow so that it does not conflict with the currently active version.

Getting the Version Number for a Flow

Unfortunately, all this means that it's pretty hard to do any useful automation around flows, because Salesforce's internal versioning strategy makes them a little hard to work with. If you need a scriptable way to get the currently active or latest version of a flow from your org, the Tooling API may help a little:

SELECT
    ActiveVersion.VersionNumber,
    LatestVersion.VersionNumber
FROM FlowDefinition
WHERE DeveloperName = 'My_Custom_Flow'

This Tooling API's "query" service can give you both the currently active and the latest version number of the flow in your org.

{
   "size": 1,
   "totalSize": 1,
   "done": true,
   "queryLocator": null,
   "entityTypeName": "FlowDefinition",
   "records": [
      {
         "attributes": {
            "type": "FlowDefinition",
            "url": "/services/data/v35.0/tooling/sobjects/FlowDefinition/..."
         },
         "Id": "...",
         "ActiveVersion": {
            "attributes": {
               "type": "Flow",
               "url": "/services/data/v35.0/tooling/sobjects/Flow/..."
            },
            "VersionNumber": 3
         },
         "LatestVersion": {
            "attributes": {
               "type": "Flow",
               "url": "/services/data/v35.0/tooling/sobjects/Flow/..."
            },
            "VersionNumber": 3
         }
      }
   ]
}

If you need to retrieve the currently active version of the flow, you can just use the flow's API name in combination with the ActiveVersion returned by this.

If you need to do something to automatically deploy new versions of the flow to your org, you can just take the LatestVersion number and add 1 to get an unused version number for the new flow.

Related Solutions

[SalesForce] Retrieve Folder Metadata using Metadata API (File based)

Folders are strange things indeed, there are four types of folders, document, email, report and dashboard, they do not exist as a physical Metadata Type, hence you don't see them listed here. Most of the time they don't work like regular Metadata components with the rest of the API either. The Folder documentation also further hints at their slightly 'special' nature!

Folders are stored in the corresponding component directory of the package. These directories are named documents, email, reports, and dashboards. Folders do not have a text file representation—they are containers for files. For each folder, an accompanying metadata file named FolderName-meta.xml is created at the same directory level. The FolderName-meta.xml metadata file contains the metadata information for that folder, such as the accessType. For example, for a documents folder named sampleFolder, there’s a sampleFolder-meta.xml within the documents folder of the package.

You cannot retrieve just the folder itself with the Metadata API retrieve operation, you have to request at least one file for it to create the folder and the associated metadata XML file for the folder. In my testing just now i can see that you can effectively put anything you like as the type when using retrieve and it just ignores (unlike other operations that throw errors) invalid ones, most misleading!

Fortunately you can use the latest readMetadata operation combined with the listMetadata to retrieve them instead! Here is an example using the Apex Metadata API to do just that...

MetadataService.MetadataPort service = new MetadataService.MetadataPort();
List<MetadataService.ListMetadataQuery> queries = new List<MetadataService.ListMetadataQuery>();
service.SessionHeader = new MetadataService.SessionHeader_element();
service.SessionHeader.sessionId = UserInfo.getSessionId();

MetadataService.ListMetadataQuery queryDocumentFolder = new MetadataService.ListMetadataQuery();
queryDocumentFolder.type_x = 'DocumentFolder';
queries.add(queryDocumentFolder);       
MetadataService.FileProperties[] fileProperties = service.listMetadata(queries, 30);
List<String> folderNames = new List<String>();
for(MetadataService.FileProperties fileProperty : fileProperties)
    folderNames.add(fileProperty.fileName.replace('documents/', ''));

List<MetadataService.DocumentFolder> folder = 
    (List<MetadataService.DocumentFolder>) 
        service.readMetadata('DocumentFolder', folderNames).getRecords();

Retrieve Metadata Demo Further Info

This screenshot shows the Retrieve Demo from the Apex Metadata API retrieving a document file and the document folder, you can see it retrieves the document metadata file. Again this only works IF you also retrieve a file as well sadly.

enter image description here

NOTE: Take a look at this code to see how the above works, to try it out enter the name of your folder in the Folder field, select Document from the drop down, select any file in the folder and click Retrieve.

[SalesForce] metadata retrieve

Are you sure the user you're using has access to those fields? I just tried to retrieve those fields, and here's the result.

Case.object:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <fields>
        <fullName>BusinessHoursId</fullName>
        <trackFeedHistory>false</trackFeedHistory>
        <trackHistory>false</trackHistory>
        <trackTrending>false</trackTrending>
        <type>Lookup</type>
    </fields>
</CustomObject>

Opportunity.object:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <fields>
        <fullName>Probability</fullName>
        <trackFeedHistory>false</trackFeedHistory>
        <trackTrending>false</trackTrending>
    </fields>
</CustomObject>

package.xml:

<types>
    <members>Case.BusinessHoursId</members>
    <members>Opportunity.Probability</members>
    <name>CustomField</name>
</types>

So as you can see, they are retrieved correctly.

Also, if you're only retrieving fields then you don't need to specify any CustomObject members. Retrieving the fields will create the relevant .object files.