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

• SFDC CLI does not deploy Standard SObject workflow elements - not found in zipped directory #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]

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: #2356

[shetzel]

Internally tracked with W-11385847

[mcarvin8]

@shetzel - is there any update on fixing deploying workflow children using the CLI? Last CLI version I checked a few weeks ago still had the issue even with the decomposed workflow preset.

Not sure if this is impacted by the upcoming deprecation of workflow rules or if this is still planned for a fix??

When I tested it recently, when I had a decomposed WorkflowAlert in my package, the CLI was able to retrieve the decomposed file but it skipped over it when trying to deploy the same package.

[shetzel]

@mcarvin8 - decomposed Workflows are supposed to solve this. With the decomposeWorkflowBeta preset did the retrieve write the decomposed file as expected (per this doc)?

If you convert just WorkflowAlert to a directory does the convert happen as expected?

What is the exact command you were using to deploy? I'll give it a try as well.

[mcarvin8]

@shetzel - the retrieve with the decomposed workflow preset worked fine.

Deploying it failed as the Salesforce CLI skipped over the entry in the package.xml for WorkflowAlert.

Just using the standard "sf project deploy start -x manifest/package.xml" in vs code (windows 11). Not in a CI/CD pipeline.

Same flags for retrieving the same package. Retrieve works with decomposed preset but deploy "passes" but didn't actually deploy anything.

I didn't try the convert command but I deploy with a manifest file so I need that command to run and actually deploy the components.

With just WorkflowAlert in the package, component count was 0 and deploy was "successful".

[mcarvin8]

@shetzel After upgrading to today's latest CLI, I still see the same behavior.

With "WorkflowAlert" in the package.xml, it deploys successfully but with 0 components.

package.xml

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

Retrieving the same package.xml has similar behavior. Is there something wrong with this package.xml??

PS C:\Users\matthew.carvin\Documents\carvin> sf project retrieve start -x .\package.xml

────────────── Retrieving Metadata ──────────────

Retrieving v59.0 metadata from matthew.carvin@avalara.com.carvin using the v62.0 SOAP API

✔ Preparing retrieve request 21ms
✔ Sending request to org 314ms
✔ Waiting for the org to respond 253ms
✔ Done 0ms

Status: Succeeded
Elapsed Time: 578ms

» Warning: Nothing retrieved

CLI version:

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.69.14",
  "nodeVersion": "node-v22.11.0",
  "osVersion": "Windows_NT 10.0.22621",
  "rootPath": "C:\\Users\\matthew.carvin\\AppData\\Local\\sf\\client\\2.69.14-c6442ee",
  "shell": "powershell",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.11 (core)",
    "@oclif/plugin-commands 4.1.12 (core)",
    "@oclif/plugin-help 6.2.18 (core)",
    "@oclif/plugin-not-found 3.2.29 (core)",
    "@oclif/plugin-plugins 5.4.19 (core)",
    "@oclif/plugin-search 1.2.16 (core)",
    "@oclif/plugin-update 4.6.14 (core)",
    "@oclif/plugin-version 2.2.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.24 (core)",
    "@oclif/plugin-which 3.2.19 (core)",
    "@salesforce/cli 2.69.14 (core)",
    "apex 3.6.6 (core)",
    "api 1.3.2 (core)",
    "auth 3.6.78 (core)",
    "data 3.12.3 (core)",
    "deploy-retrieve 3.15.17 (core)",
    "dev 2.4.2 (user) published 106 days ago (Mon Aug 26 2024) (latest is 2.5.1)",
    "info 3.4.25 (core)",
    "limits 3.3.42 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.7 (core)",
    "packaging 2.9.5 (core)",
    "schema 3.3.43 (core)",
    "settings 2.4.8 (core)",
    "sobject 1.4.46 (core)",
    "telemetry 3.6.26 (core)",
    "templates 56.3.33 (core)",
    "trust 3.7.45 (core)",
    "user 3.6.4 (core)",
    "apex-code-coverage-transformer 2.0.0 (user) published 51 days ago (Mon Oct 21 2024) (latest is 2.2.0)",
    "apex-tests-git-delta 2.0.0 (user) published 51 days ago (Mon Oct 21 2024)",
    "apextestlist 1.9.1 (user) published 30 days ago (Sun Nov 10 2024)",
    "sf-package-combiner 1.2.3 (user) published 0 days ago (Tue Dec 10 2024)",
    "sfdx-git-delta 5.49.0-dev-942.11663286254-1 (user) published 37 days ago (Mon Nov 04 2024) (latest is 5.50.0)"
  ]
}

[shetzel]

Looks like you're doing everything correct to me. I'm seeing the same behavior so it's doubtful that workflow children were addressable by the CLI (or VS Code extension) like this.

The simple way to test this is to do a convert of the source to mdapi format using your manifest. E.g.,
sf project convert source -x package.xml -d convertedWorkflowAlert
If you look at the directory it doesn't contain anything and that's what happens during the deploy.

So this is a bug. You'll have to deploy/retrieve the entire workflow as a workaround. As you pointed out, Workflows are deprecated and that affects the priority of the bug fix but we'll look into it.

[mcarvin8]

Thanks.

Glad to see it's reproducible but I understand it's low priority since workflows are deprecated.