SFDX CLI does not deploy Standard SObject workflow elements -- Deployed Source No results found

[ImJohnMDaniel]

Summary

Salesforce CLI appears to be unable to deploy workflow elements for Standard objects when those workflow elements are specified in the package.xml as individual metadata elements (i.e. WorkflowRule, WorkflowAlert, WorkflowFieldUpdate, etc.) and not as a whole workflow metadata element (i.e. Workflow).

Steps To Reproduce:

1. Create a workflow rule with a workflow email alert and workflow field update on the Account object
2. Create a package.xml file listing each of the elements individually in WorkflowRule, WorkflowAlert, WorkflowFieldUpdate, metadata types.
3. Retrieve the metadata. (this works correctly)
4. Deploy the workflow to another org. (Failure point)

Expected result

The workflow elements should be deployed to the target org

Actual result

No deployment occurs. The error seen is:

=== Deployed Source
No results found

Additional information

SFDX CLI Version(to find the version of the CLI engine run sfdx --version):

sfdx-cli/7.77.0-112dd7d412 darwin-x64 node-v12.18.3

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core)

@oclif/plugin-autocomplete 0.2.0
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.2 (core)
analytics 1.12.1 (core)
auth 1.3.0 (core)
config 1.1.9 (core)
generator 1.1.3 (core)
salesforcedx 50.2.0 (core)
├─ templates 50.1.0 (core)
├─ custom-metadata 1.0.10 (core)
├─ salesforce-alm 50.2.0 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
└─ apex 0.1.1 (core)
sfdmu 3.7.17
sfdx-cli 7.77.0 (core)
shane-sfdx-plugins 4.41.2
├─ @mshanemc/sfdx-sosl 1.1.0
└─ @mshanemc/plugin-streaming 1.1.7
soqlx-opener 0.1.12

OS and version:
MacOS v10.15.7

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[dmgerow]

I can confirm that I am also seeing this issue

[geraemartinez]

this issue is still happening in Windows 10 as well, does anyone have an ETD?

[sayantadandapat]

Hi We are not able to deploy the WorkFlowAlert and Workflow Rule with sfdx-cli/7.81.0-7b953c80d1 win32-x64 node-v12.18.3 version.Whenever we try to deploy the WorkFlowAlert and Workflow Rule it is saying "No Result Found" and showing an success message that deployment is successfull.
But nothing is deployed into the target org.
This is becoming a critical issue for us.
Please address this with upcoming CLI and fix that for our smooth deployment.

[geraemartinez]

I fixed the issue by adding the Workflow types element to my package.xml along with my workflow items

    </types>
         <members>MY_SOBJECT.MY_FIELD_UPDATE_NAME</members>
        <name>WorkflowFieldUpdate</name>
    </types>
    <types>
        <members>MY_SOBJECT.MY_TASK_NAME</members>
        <name>WorkflowTask</name>
    </types>

    <!-- this one is the important -->
    <types>
        <members>MY_SOBJECT</members>
        <name>Workflow</name>
    </types>
    <!-- this one is the important -->

[ImJohnMDaniel]

@geraemartinez -- Thanks for the suggestion but that won't work in my case. If I specify the Workflow element for Account or Case, I end up with all workflow rules on the SObject found in the org and not just the select rules that pertain to my application alone. The Metadata API guide does say that this approach of specifying the individual rules is permissible and thus my only conclusion is that it is a bug with CLI.

[geraemartinez]

@ImJohnMDaniel I agree, this was not happening before, my approach is just a temporary workaround (I hope), anyway, just to explain more my solution, when I am packaging my solution I am only retrieving specific workflow rules of the Account and Lead objects, not all of them, just as we normally used to do, specifying WorkflowTask, WorkflowFieldUpdate, etc.

then when I finished, I go to the workflow rules to make sure that I only see the elements that I specified in my package.xml, if so I add the workflow type (<types> <members>MY_SOBJECT</members> <name>Workflow</name> </types>) to the package.xml, therefore I am adding that element only when I finished to package everything or just when I am about to deploy the packages, in that way the issue does not come up again and I am able to deploy just the metadata that I retrieved.

hope it helps.

[iandrosov]

Based on Metadata Tags separate deploy or even Item deploy should be possible. But in practice, it does not work with SFDX CLI. As I found only way CLIS pull say Workflow on COntact is by pulling in Contact.workflow file that has ALL WF rules and other components even Packaged one. BUt if I want only to manage my custom parts it seem to be broken

[qwikag]

This is still broken on 7.89.2

The workaround seems OK, but I would do it a little differently.

I would create a separate retrieve_workflow.xml and deploy_workflow.xml, and maybe package.xml would be my final.
As suggested above retrieve.xml contains the specifics and deploy.xml contains object (highlevel) workflow xml only, e.g....
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>Opportunity</members> <name>Workflow</name> </types> <version>50.0</version> </Package>

This works

But the normal way is definitely a bug!

[ar-srinivas]

I am still facing this issue even on 7.98.0 version as well.

[demodigit92]

I am still facing the issue even on sfdx-cli/7.99.0 darwin-x64 node-v12.18.3

A workaround is do deploy using MDAPI instead of source API, this way we don't need to include workflow metadata, only WorkflowAlert

[saakshigupta-rubrik]

This issue still persists in version 7.102.0.

I changed the name of a workflow rule and it deleted the workflow rule with the old name but didn't create the one with the new name.

[shetzel]

@saakshig - have you tried this using the new source plugin beta? See the announcement here: #1057

[IVerkhosh]

The issue is still in the sfdx-cli/7.108.0 win32-x64 node-v14.17.1
We are not using mdapi format, just source and it is not working

[shetzel]

@IVerkhosh - have you tried this using the new source plugin beta? See the announcement here: #1057. The plugin will become the production version very soon (maybe even this week Thursday) so knowing if the new plugin fixes the issue is really helpful.

[IVerkhosh]

Hi @ shetzel,
I tried to install it, but was getting the error Error: self signed certificate in certificate chain.
Can this be installed manually?

[shetzel]

@IVerkhosh - you no longer need to install the beta plugin since it's no longer beta and being used as a core plugin. so if you're running the latest CLI version then you have the latest and don't need to do anything else. However, I know that this still doesn't work correctly. Workflows as well as other parent types (e.g., SharingRules) that are not decomposed all have this problem and I'm working on a solution for them.

[IVerkhosh]

Hi @shetzel - thank you for the update. At this time I have to PC's with two different versions, 7.110 and 7.116
If I can help, I will be glad to test the incoming updates, as my org is a big one.

[shetzel]

@IVerkhosh - thanks I'll let you know when it's in the plugin.

[shetzel]

I believe I have this fixed in the SDR repo with this PR: forcedotcom/source-deploy-retrieve#446

Once it's approved and merged and consumed in the source plugin and CLI I'm hopeful that these parent types work better for everyone.

[mzanini]

Same problem here on version 7.116.2. This essentially prevents me from pushing the converted source to my packaging org since I get an error saying that the workflow rule and outboundMessage are not in the package.xml. Eagerly awaiting the fix to be released @shetzel!

[shetzel]

The current CLI release candidate (7.118.1) should have the fix for people to try. Feel free to install the RC to test, then go back to the production CLI version. The RC will be promoted this Thursday.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. Currently, there is not enough information provided for us to take action. Please reply and reopen this issue if you need additional assistance.

[JavierCarvajalLBS]

I have exactly the same issue today deploying Opportunity standard object Email Alerts or Workflow Rules using CLI 7.119.2 win32-x64

I receive the following error messages:

An object XXX of type WorkflowAlert was named in package.xml, but was not found in zipped directory
An object XXX of type WorkflowRule was named in package.xml, but was not found in zipped directory

Any idea about how to fix it?

[vineet-goel-salesforce]

I am also facing this issue, while deploying WorkflowAlert, I am getting the below error.
An object XXXXXXX of type WorkflowAlert was named in package.xml, but was not found in zipped directory

[shetzel]

@vineet-goel-salesforce - Are you trying to deploy a WorkflowAlert individually, meaning without the parent Workflow? That won't work. Children of Workflows cannot be deployed like children of CustomObjects because Workflows are not decomposed. You'll have to deploy the entire Workflow. E.g., sfdx force:source:deploy -m Workflow or sfdx force:source:deploy -m Workflow:MyWorkflowName

EDIT: now that I read the whole thread, I don't think this was ever supported and I don't see anything in the metadata API docs that state it should be possible. Looks like the tooling API supports this but the CLI uses the metadata API for deploy/retrieve.

[JavierCarvajalLBS]

@shetzel but what happens if I just want to deploy one WorkflowAlert?
Because the Workflow contains all the WorkflowAlert, WorkflowRule, FieldUpdate and OutboundMessage and I just need to deploy one specific element of the entire Workflow, not all of them.
I can do it in a changeset including only the Email Alert, so I guess it should be possible with Metadata API, isn´t it?

[vineet-goel-salesforce]

@shetzel - In my case I have Email Alert and that alert has been used in apex, hence I only want to deploy email alert (WorkflowAlert) and class, I don't want to deploy my sObject WorkflowRule, FieldUpdate and OutboundMessage, how can I achieve that through Metadata API?

[JavierCarvajalLBS]

@shetzel why it is possible to retrieve the Children of Workflows using a package.xml file that only contains those elements but you receive the error message if you try to deploy them using exactly the same file?
The Workflows are not decomposed for both, but you can use it for retrieving, and it retrieves the specific information, but you cannot use the same for deployment. It doesn´t seem to have sense, right?

@vineet-goel-salesforce you can do it by removing all the other elements in the workflow element and deploying the workflow instead.
In my case it is not a good solution because it involves human work to update the workflow metadata file and we want to use it in a CI/CD implementation, so no human intervention should be required.

[itaishmida]

I am also facing this problem
With sfdx CLI I can easily get the WorkflowRule with the sfdx force:source:retrieve -m command, but when trying to deploy it with the sfdx force:source:deploy -m command, I get this error:
Error myObject__c.myWorkflowRuleName An object 'myObject__c.myWorkflowRuleName' of type WorkflowRule was named in package.xml, but was not found in zipped directory

[tggagne]

The best work-around I've found is to use a retrieve package.xml that specifies the individual pieces, then a deploy package.xml with the entire workflow. I'm still queasy with this approach because it means I need to keep two package files in-sync.

Using sfdx-cli/7.147.1 darwin-x64 node-v16.15.0

[justin-lyon]

@mshanemc what additional information are we missing here? I'm running into the issue still today.

sfdx version        
sfdx-cli/7.180.0 darwin-arm64 node-v18.1.0

sfdx plugins --core
@oclif/plugin-autocomplete 1.3.6 (core)
@oclif/plugin-commands 2.2.1 (core)
@oclif/plugin-help 5.1.19 (core)
@oclif/plugin-not-found 2.3.9 (core)
@oclif/plugin-plugins 2.1.7 (core)
@oclif/plugin-search 0.0.4 (core)
@oclif/plugin-update 3.0.7 (core)
@oclif/plugin-version 1.1.3 (core)
@oclif/plugin-warn-if-update-available 2.0.14 (core)
@oclif/plugin-which 2.2.2 (core)
@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)
alias 2.1.10 (core)
apex 1.3.0 (core)
auth 2.3.0 (core)
community 2.0.18 (core)
config 1.4.22 (core)
custom-metadata 2.0.5 (core)
data 2.1.10
generator 2.0.12 (core)
info 2.2.10 (core)
limits 2.1.2 (core)
org 2.2.15 (core)
packaging 1.10.9 (core)
salesforce-alm 54.8.4 (core)
schema 2.1.17 (core)
sfdmu 4.17.6
sfdx-cli 7.180.0 (core)
signups 1.2.12 (core)
source 2.3.7 (core)
telemetry 2.0.5 (core)
templates 55.1.0 (core)
trust 2.1.0 (core)
user 2.1.21 (core)

[RupertBarrow]

HI all, I think this case needs to be reopened so that Shane puts it back on the pile.

[dakotalim54]

I am still seeing this in the sf CLI on v2.24.4 and have to use @geraemartinez referenced above from years ago