0

I need to get metadata files from manually created Workflow Field Update actions. I created package.xml with following content:

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

then, I tried to retrieve metadata:

dzmitry@debian:/tmp/test-backend/unpackaged$ rm -rf *; sf force:mdapi:retrieve -o test-backend2 --unzip --unpackaged package.xml --retrievetargetdir /tmp/test-backend › Warning: @salesforce/cli update available from 2.45.6 to 2.53.6. Warning: We plan to deprecate this command in the future. Try using the "project retrieve start" command instead. Retrieving v61.0 metadata from [email protected] using the v61.0 SOAP API Retrieve ID: 09SH4000000G4cuMAC Retrieving metadata from [email protected]... done Wrote retrieve zip to /tmp/test-backend/unpackaged.zip Extracted unpackaged.zip to: /tmp/test-backend/unpackaged dzmitry@debian:/tmp/test-backend/unpackaged$ find . ./unpackaged ./unpackaged/package.xml ./unpackaged/workflows ./unpackaged/workflows/Case.workflow ./unpackaged/workflows/Account.workflow ./unpackaged/workflows/Quote.workflow 

However, those files is not all FieldUpdate workflows. Tooling soql api returns more of them:

dzmitry@debian:~/work/veloce-integration1$ sf data query -t -o test-backend2 --query 'select Name,Fullname from WorkflowFieldUpdate limit 100' › Warning: @salesforce/cli update available from 2.45.6 to 2.54.6. NAME FULLNAME ────────────────────────────────── ──────────────────────────────────────────── Changes the case priority to high. Case.ChangePriorityToHigh RejectedFieldUpdate <Company prefix>__ApprovalItem__c.RejectedFieldUpdate Quote1 Quote.Quote1 Quote Quote.Quote ApprovedFieldUpdate <Company prefix>__ApprovalItem__c.ApprovedFieldUpdate Approval <Company prefix>__ApprovalItem__c.Approval Account Account.Account RecalledFieldUpdate <Company prefix>__ApprovalItem__c.RecalledFieldUpdate Case1 Case.Case1 Total number of records retrieved: 9. Querying Data... done 

As you can see, mdapi retrived Case, Account, Quote workflows, but failed with __ApprovalItem__c related workflows.
Any ideas mdapi doesn't return all metadata?
How to get __ApprovalItem__c metadata files?

UPD: I also tried package.xml with ApprovalProcess type. The result is approval process with actions, but it only has name and type:

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

Response:

<?xml version="1.0" encoding="UTF-8"?> <ApprovalProcess xmlns="http://soap.sforce.com/2006/04/metadata"> <active>true</active> <allowRecall>true</allowRecall> <allowedSubmitters> <type>owner</type> </allowedSubmitters> <approvalPageFields> <field>Name</field> <field>Owner</field> </approvalPageFields> <approvalStep> <allowDelegate>false</allowDelegate> <assignedApprover> <approver> ... </approver> <whenMultipleApprovers>FirstResponse</whenMultipleApprovers> </assignedApprover> <label>Step1</label> <name>Step1</name> </approvalStep> <enableMobileDeviceAccess>false</enableMobileDeviceAccess> <finalApprovalActions> <action> <name>ApprovedFieldUpdate</name> <type>FieldUpdate</type> </action> </finalApprovalActions> <finalApprovalRecordLock>false</finalApprovalRecordLock> <finalRejectionActions> <action> <name>RejectedFieldUpdate</name> <type>FieldUpdate</type> </action> </finalRejectionActions> <finalRejectionRecordLock>false</finalRejectionRecordLock> <label>ApprovalProcess1</label> <processOrder>1</processOrder> <recallActions> <action> <name>RecalledFieldUpdate</name> <type>FieldUpdate</type> </action> </recallActions> <recordEditability>AdminOnly</recordEditability> <showApprovalHistory>false</showApprovalHistory> </ApprovalProcess> 

1 Answer 1

0

Retrieving Workflow retrieves Workflow Rules and their actions. The "missing" actions that you're asking about would be retrieved via ApprovalProcess. When salesforce.com designed Approval Processes, they reused the various Workflow action types, since they serve the same purpose in terms of automation, and they didn't need any additional properties.

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.