Converting/deploying/retrieving Workflows and its children is broken

[amtrack]

Summary

Converting and deploying and retrieving Workflows and child types like WorkflowFieldUpdate is broken.

I'm aware that Workflow is currently not decomposed but I think it could be easily decomposed because it contains only fully addressable child components.
The described behavior further shows that in non-decomposed form, Workflow cannot be placed in multiple package directories.

Steps To Reproduce:

The following repo contains 3 WorkflowFieldUpdate components split over multiple package directories:

• force-app: Case.ChangePriorityToHigh, Case.ChangePriorityToMedium
• another-package: Case.ChangePriorityToLow

Repository to reproduce: mdapi-issues/sfdx-workflow-handling

1. sfdx force:source:convert -m Workflow:Case -d mdapi
2. sfdx force:source:convert -m WorkflowFieldUpdate:Case.ChangePriorityToHigh -d mdapi
3. sfdx force:source:retrieve -m WorkflowFieldUpdate:Case.ChangePriorityToHigh

Expected result

1. Converts all 3 components into a single mdapi/workflows/Case.workflow metadata file
2. Converts only the given WorkflowFieldUpdate to mdapi/workflows/Case.workflow metadata file
3. Retrieves the given WorkflowFieldUpdate and appends it to force-app/main/default/workflows/Case.workflow-meta.xml or updates another-package/workflows/Case.workflow-meta.xml

Actual result

1. Only the workflow components of the last package directory (here: Case.ChangePriorityToLow) are converted to mdapi/workflows/Case.workflow
2. All children of the first packaging directory are converted and the folder name is invalid (workflowFieldUpdates instead of workflows): mdapi/workflowFieldUpdates/Case.workflow
3. force-app/main/default/workflows/Case.workflow-meta.xml is overwritten

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)
• --> zsh

$ sfdx version --verbose --json
{
        "cliVersion": "sfdx-cli/7.156.1",
        "architecture": "darwin-arm64",
        "nodeVersion": "node-v16.13.1",
        "pluginVersions": [
                "@oclif/plugin-autocomplete 0.3.0 (core)",
                "@oclif/plugin-commands 1.3.0 (core)",
                "@oclif/plugin-help 3.3.1 (core)",
                "@oclif/plugin-not-found 1.2.6 (core)",
                "@oclif/plugin-plugins 1.10.11 (core)",
                "@oclif/plugin-update 1.5.0 (core)",
                "@oclif/plugin-warn-if-update-available 1.7.3 (core)",
                "@oclif/plugin-which 1.0.4 (core)",
                "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
                "alias 2.1.0 (core)",
                "apex 0.13.0 (core)",
                "auth 2.2.0 (core)",
                "community 2.0.0 (core)",
                "config 1.4.12 (core)",
                "custom-metadata 2.0.0 (core)",
                "data 2.0.4 (core)",
                "generator 2.0.1 (core)",
                "info 2.0.1 (core)",
                "limits 2.0.1 (core)",
                "org 1.13.2 (core)",
                "salesforce-alm 54.6.0 (core)",
                "schema 2.1.1 (core)",
                "sfdx-cli 7.156.1 (core)",
                "signups 1.2.0 (core)",
                "source 2.0.2 (core)",
                "telemetry 2.0.0 (core)",
                "templates 55.0.0 (core)",
                "trust 2.0.1 (core)",
                "user 2.1.0 (core)"
        ],
        "osVersion": "Darwin 21.5.0"
}

Additional information

[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.

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[git2gus[bot]]

This issue has been linked to a new work item: W-11385847

[mshanemc]

related discussion: #2544

[shetzel]

Reported GH issues on this topic:
#707
#1228
#1591 (this discussion is based on this reported issue)
#2563

[mcarvin8]

In my opinion, when deploying workflow children is fixed, it would be nice to allow child workflows to be separated into their own meta files rather than all workflows for a Parent being contained in 1 meta file.

Something like this:
Parent Workflow: Case
Child Workflow: Another_alert (Email Alert)
Potential File Name: force-app/main/default/workflows/Case.alerts_Another_alert.workflow-meta.xml (or something else - just brainstorming)

My team keeps running into the issue of overwriting workflows depending on how the person retrieves the workflow (if they just retrieve 1 child workflow, it overwrites the entire workflow meta file). A couple of guys on team wish that workflow files were more granular so that you could deploy just 1 child workflow file without affecting other child workflows from the same parent.

Since deploying Children Workflows is already broken via the CLI, it could be an opportunity to update how the CLI creates workflow meta files upon retrieval.

[mshanemc]

see screenshot below for how the decomposition works (1 file per fieldUpdate/etc, in a folder for the each sobject)

You're left with an "empty" parent object since everything can be decomposed. I guess if your workflow had a fullName that could stay in the top-level file?

[mshanemc]

I can confirm that all these scenarios work with the new feature. Also tried a few other things (esp around deleting and change tracking).

[TWood-IRL]

Hey @mshanemc is there any indication of when this is GA ?

[VivekMChawla]

@TWood-IRL - Hello! I'm the PM for the Salesforce CLI.

The source decomposition functionality for workflows (and other metadata types) was originally envisioned as a set of presets for a customizable metadata registry, allowing customers to create their own decomposition rules, resulting in any source structure they wanted.

We later decided to remove support for customer-customizations, meaning that the "presets" that Salesforce publishes for a given metadata type, like Workflows, will be the only decomposition option.

This makes decisions on the structure of decompositions much more important than when we were just offering "presets" that customers could tweak if they wanted to.

This means that the path to GA for this feature is two-fold.

1. The source decomposition feature itself (meaning the new code in our libraries and plugins) needs to go through the beta process to find and eliminate bugs before going GA.
2. The decomposition strategy for each type will need some level of community feedback before we say the decomposition option for that type is GA.

Timing-wise, I think this is something that we'll be able to get done in time for the Winter '25 release.

[mcarvin8]

@TWood-IRL - If you'd like, you can take a look at my 3rd party Salesforce CLI plugin that offers a similar decomposition on top of the existing metadata configuration (i.e. 1 workflow file with the parent and children combined). https://github.com/mcarvin8/sf-decomposer

Obviously, it's a 3rd party plugin, which means it's not an official Salesforce solution and it works slightly differently than Salesforce's custom registry which is in the Beta phase. My plugin is designed to break down XMLs for version control and rebuild the XMLs for deployments. I believe Salesforce's beta reads the decomposed files directly when you want to deploy them.

My advice would be to test both solutions out in a sandbox to see what approach you would like to use. Ultimately your call.