cli icon indicating copy to clipboard operation
cli copied to clipboard

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

Open marioluissc opened this issue 2 months ago • 4 comments

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 <flowAccesses> 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

marioluissc avatar May 03 '24 03:05 marioluissc

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] avatar May 03 '24 03:05 github-actions[bot]

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.

mdonnalley avatar May 03 '24 15:05 mdonnalley

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.

github-actions[bot] avatar May 03 '24 15:05 github-actions[bot]

You should use Permission Sets for access :)

nvuillam avatar May 06 '24 15:05 nvuillam