I can't deploy private Lightning Email Templates distributed in folders and subfolders up to three levels

[carlosabella]

Note Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

I have private Lightning Email Templates distributed in folders and subfolders up to three levels. I can retrieve without any problem, but I can't deploy them.

I have the following structure of private folders and subfolders:

• CarlosFolder
• --- CarlosFolderlevel2
• ------- CarlosFolderlevel3
• ------- New_Template_here_level_three_1644944118232.email

I can retrieve correctly by using a manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
     <types>
        <members>CarlosFolder</members>
        <members>CarlosFolder/CarlosFolderlevel2/</members>
        <members>CarlosFolder/CarlosFolderlevel2/CarlosFolderlevel3</members>
        <members>CarlosFolder/CarlosFolderlevel2/CarlosFolderlevel3/New_Template_here_level_three_1644944118232</members>
        <name>EmailTemplate</name>
    </types>
    <version>59.0</version>
</Package>

I retrieve using: sf project retrieve start -x manifest/package.xml And this is the result:

Then I do a change in the .email file and I want to deploy by using exactly same manifest: sf project deploy start -x manifest/package.xml I get the following error:

Steps To Reproduce

IMPORTANT Provide a repository that's configured to reproduce the issue. If you are unable to provide a repo, please explain why not. The more info we have from the start, the faster we can resolve your issue. We may close your issue if you don't include proper instructions.

• Generate a project with sf project generate or fork dreamhouse-lwc.
• Provide detailed step-by-step instructions on how to reproduce the issue. This is the repository where you can find an example of the code I can't deploy: https://github.com/carlosabella/carlosabella-Lightning-Email-Templates-problem

1.- Having the following structure of nested folders and subfolders in Lightning Email Templates

• CarlosFolder
• --- CarlosFolderlevel2
• ------- CarlosFolderlevel3
• ------- New_Template_here_level_three_1644944118232.email

2.- Retrieve the template to local by using: sf project retrieve start -x manifest/package.xml This is the manifest file:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
     <types>
        <members>CarlosFolder</members>
        <members>CarlosFolder/CarlosFolderlevel2/</members>
        <members>CarlosFolder/CarlosFolderlevel2/CarlosFolderlevel3</members>
        <members>CarlosFolder/CarlosFolderlevel2/CarlosFolderlevel3/New_Template_here_level_three_1644944118232</members>
        <name>EmailTemplate</name>
    </types>
    <version>59.0</version>
</Package>

The email template and the nested folder structure is retrieved correctly as it is in the repository named above.

3.- After a change in the email template I use the same package .xml to deploy by using the following command: sf project deploy start -x manifest/package.xml

Expected result

Deploy is successful

Actual result

Error CarlosFolder/CarlosFolderlevel2/ An object 'CarlosFolder/CarlosFolderlevel2/' of type EmailTemplate was named in package.xml, but was not found in zipped directory

System Information

I am using zsh

{
  "architecture": "darwin-x64",
  "cliVersion": "@salesforce/cli/2.24.4",
  "nodeVersion": "node-v20.10.0",
  "osVersion": "Darwin 23.2.0",
  "rootPath": "/Users/cgarcia/.local/share/sf/client/2.24.4-c9898a2",
  "shell": "zsh",
  "pluginVersions": [
    "@copado/copado-cli 3.0.0 (link) /Users/cgarcia/Projects/Copado/copado-cli",
    "@copado/copadodev-cli 1.3.2 (user)",
    "@oclif/plugin-autocomplete 3.0.5 (core)",
    "@oclif/plugin-commands 3.1.0 (core)",
    "@oclif/plugin-help 6.0.10 (core)",
    "@oclif/plugin-not-found 3.0.8 (core)",
    "@oclif/plugin-plugins 4.1.15 (core)",
    "@oclif/plugin-search 1.0.11 (core)",
    "@oclif/plugin-update 4.1.7 (core)",
    "@oclif/plugin-version 2.0.11 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.9 (core)",
    "@oclif/plugin-which 3.0.14 (core)",
    "@salesforce/cli 2.24.4 (core)",
    "apex 3.0.17 (core)",
    "auth 3.2.0 (core)",
    "data 3.0.14 (core)",
    "deploy-retrieve 3.1.0 (core)",
    "dev 2.1.4 (user)",
    "info 3.0.15 (core)",
    "limits 3.1.2 (core)",
    "marketplace 1.0.16 (core)",
    "org 3.2.2 (core)",
    "packaging 2.1.1 (user)",
    "schema 3.1.0 (core)",
    "settings 2.0.15 (core)",
    "sobject 1.1.0 (core)",
    "source 3.1.3 (core)",
    "telemetry 3.1.9 (core)",
    "templates 56.0.9 (core)",
    "trust 3.3.1 (core)",
    "user 3.2.1 (core)",
    "@salesforce/sfdx-scanner 3.20.0 (user)"
  ]
}

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.

[git2gus[bot]]

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

[shetzel]

Thanks for the great repro steps. Looks like a bug specifically with matching components in the project using a manifest. It misses CarlosFolder/CarlosFolderlevel2/.

As a workaround, you can do sf project deploy start -d force-app.

[WillieRuemmele]

Hey @carlosabella - after looking at this issue again, I've confirmed that the bug lies within in the <members>CarlosFolder/CarlosFolderlevel2/</members>

if you change it to <members>CarlosFolder/CarlosFolderlevel2</members>

(without the trailing /) it will deploy and retrieve successfully. I confirmed that when running

sf project generate manifest --source-dir force-app/main/default/email --name email

it generated a manifest correctly, without the /

[carlosabella]

@WillieRuemmele Thanks for the answer. But still ... I have to say it is not consistent same manifest can retrieve but it can't deploy. Thanks a lot.