forcedotcom / cli

Salesforce CLI
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/
BSD 3-Clause "New" or "Revised" License
494 stars 78 forks source link

<flowAccesses> not included on Profile when retrieving Metadata by Package Name #2856

Open marioluissc opened 7 months ago

marioluissc commented 7 months ago

Summary

<flowAccesses> not included on Profile xml metadata when retrieving metadata using sf CLI project retrieve start by Package Name (-n) attribute.

Example CLI: sf project retrieve start -t path/to/dir -n {CHANGE_SET_NAME} --api-version 60.0

Steps To Reproduce

a) Create a simple Screen Flow (the logic or content of the flow is not relevant). b) Edit Access for the flow just created, then add permission to execute the flow to at least 1 Profile. example:

image

c) Create a Outbound Change Set, give it a name (the name will be used on the CLI later) d) Add the "Flow Definition" component created on step a) the change set e) Add the "Profile(s)" that you configured on step b) to the change set f) Run the following CLI, replacing the CHANGE_SET_NAME with the name you gave to your change set.

sf project retrieve start -t path/to/dir -n CHANGE_SET_NAME --api-version 60.0 

g) On the package retrived, open one of the profiles files retrived (eg. profileName.profile) and notice that <flowAccesses> node is not included on its content.

So when I try to deploy the package to another org, the flow permission are lost.

Extra Information and some extra tests I did: This is the package.xml resulted from the CLI above:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>CHANGE_SET</fullName>
    <types>
        <members>BOD_1_1_Classes</members>
        <name>Flow</name>
    </types>
    <types>
        <members>Admin</members>
        <name>Profile</name>
    </types>
    <version>60.0</version>
</Package>

Inspired on this article https://gearset.com/blog/what-is-the-salesforce-metadata-flowaccesses/ I modified the package.xml above and included a "FlowDefinition" metadata type as per below.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>CHANGE_SET</fullName>
    <types>
        <members>BOD_1_1_Classes</members>
        <name>Flow</name>
    </types>
    <types>
        <members>BOD_1_1_Classes</members>
        <name>FlowDefinition</name>
    </types>
    <types>
        <members>Admin</members>
        <name>Profile</name>
    </types>
    <version>60.0</version>
</Package>

then I ran the following CLI based on the package manifest above

 sf project retrieve start -t path/to/dir --manifest package.xml -a 60.0

and voila!! now the profile metadata was retrieved with the content.

As per the article and salesforce own documentation, FlowDefinition type was deprecated a while back, so I wonder why is it necessary in this case and b) why retrieving metadata by the package name would not included it automatically.

Expected result

The profile file retrieved should contain a XML node as per below:

 <flowAccesses>
        <enabled>true</enabled>
        <flow>FLOW_NAME</flow>
  </flowAccesses>

image

Actual result

<flowAccesses> content is not present in the profile metadata.

System Information

MacOS -> Terminal on VS Code

{
  "architecture": "darwin-x64",
  "cliVersion": "@salesforce/cli/2.39.6",
  "nodeVersion": "node-v21.6.0",
  "osVersion": "Darwin 23.4.0",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.16 (core)",
    "@oclif/plugin-commands 3.3.1 (core)",
    "@oclif/plugin-help 6.0.21 (core)",
    "@oclif/plugin-not-found 3.1.6 (core)",
    "@oclif/plugin-plugins 5.0.14 (core)",
    "@oclif/plugin-search 1.0.23 (core)",
    "@oclif/plugin-update 4.2.7 (core)",
    "@oclif/plugin-version 2.0.17 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.15 (core)",
    "@oclif/plugin-which 3.1.8 (core)",
    "@salesforce/cli 2.39.6 (core)",
    "apex 3.1.9 (core)",
    "auth 3.6.3 (core)",
    "data 3.3.2 (core)",
    "deploy-retrieve 3.6.6 (core)",
    "info 3.2.3 (core)",
    "limits 3.3.4 (core)",
    "marketplace 1.2.4 (core)",
    "org 4.1.3 (core)",
    "packaging 2.4.0 (core)",
    "schema 3.3.4 (core)",
    "settings 2.2.1 (core)",
    "sobject 1.3.6 (core)",
    "source 3.3.3 (core)",
    "telemetry 3.3.4 (core)",
    "templates 56.2.4 (core)",
    "trust 3.6.6 (core)",
    "user 3.5.2 (core)"

Additional information

github-actions[bot] commented 7 months ago

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.

mdonnalley commented 7 months ago

Unfortunately metadata API support for Profiles isn't great. Customers have reported similar issues in the past (see this comment).

I'm going to mark this as owned by another team since we don't own the metadata API or Profiles.

github-actions[bot] commented 7 months ago

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

nvuillam commented 6 months ago

You should use Permission Sets for access :)