WorkflowAlerts Can Only Be Retrieved, Not Deployed via the CLI

[mcarvin8]

Summary

The metadata type WorkflowAlert can be successfully retrieved from the org using the CLI. However, when you attempt to deploy this metadata type with the same manifest file, the deployment will fail with An object XXXXXXXX of type WorkflowAlert was named in package.xml, but was not found in zipped directory. The same applies for other child metadata types under Workflow. The only way to currently deploy workflow related items is by using the Workflow metadata type.

Please update the CLI to allow deployments with WorkflowAlert and other children metadata types under Workflow.

We are only able to move Email Alerts by themselves via Change Set. The file created by CLI retrievals for Email Alerts matches the file created for a change-set, so it seems to be compatible for deployments.

I found other issues regarding this but they were closed

• https://github.com/forcedotcom/cli/issues/1228 (closed due to no response. Only workaround given is to use Workflow, which deploys the entire Workflow over just the email alert)
• https://ideas.salesforce.com/s/idea/a0B8W00000H4r9GUAR/we-need-to-be-able-to-deploy-workflowrelated-elements-as-we-do-for-retrieving

Steps To Reproduce

• Update the manifest file with WorkflowAlert
• Retrieve manifest from org
• Deploy manifest to org

Expected result

Retrieve and deploy completes successfully.

Actual result

Retrieve completes successfully. Deploy fails with An object XXXXXXXX of type WorkflowAlert was named in package.xml, but was not found in zipped directory.

System Information

Seen on Windows 11/PowerShell and Linux Ubuntu/Bash.

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.16.7",
  "nodeVersion": "node-v20.8.1",
  "osVersion": "Windows_NT 10.0.22621",
  "rootPath": "C:\\Users\\matthew.carvin\\AppData\\Local\\sf\\client\\2.16.7-ee67deb",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.1 (core)",
    "@oclif/plugin-commands 3.0.5 (core)",
    "@oclif/plugin-help 6.0.5 (core)",
    "@oclif/plugin-not-found 3.0.2 (core)",
    "@oclif/plugin-plugins 4.0.1 (core)",
    "@oclif/plugin-search 1.0.5 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.4 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.7 (core)",
    "@salesforce/cli 2.16.7 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.25 (core)",
    "data 2.6.1 (core)",
    "deploy-retrieve 1.19.3 (core)",
    "info 2.6.51 (core)",
    "limits 2.3.41 (core)",
    "login 1.2.40 (core)",
    "marketplace 0.3.2 (core)",
    "org 2.11.7 (core)",
    "schema 2.3.32 (core)",
    "settings 1.4.37 (core)",
    "sobject 0.2.14 (core)",
    "source 2.10.46 (core)",
    "telemetry 2.3.8 (core)",
    "templates 55.5.17 (core)",
    "trust 2.6.22 (core)",
    "user 2.3.41 (core)",
    "sfdx-git-delta 5.28.0 (user)"
  ]
}

[github-actions[bot]]

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.

[shetzel]

Yes, this behavior is broken and has been for a long time. The workaround is to deploy/retrieve the entire Workflow. I understand that the metadata API allows addressing Workflow children individually so we will be trying to solve this very soon.

There is a discussion on this topic here: https://github.com/forcedotcom/cli/discussions/2356

[shetzel]

Internally tracked with W-11385847