Recently, a new item of Salesforce metadata started showing up unexpectedly in Gearset org comparisons and monitoring jobs. Some of Gearset’s users spotted flowAccesses in their Profile metadata, and asked us about this mystery metadata.
We help users to solve their problems every day, so we’re good at getting to the bottom of these kinds of puzzles. But this was an especially interesting puzzle because flowAccesses isn’t listed among the other items of Profile metadata in Salesforce’s metadata API developer guide. In fact, as of yet, there’s no Salesforce documentation anywhere on flowAccesses.
Together with our amazing users we’ve worked out how this metadata is retrieved, and we’re confident that we’ve worked out what flowAccesses metadata is for. We’re sharing what we’ve found for the benefit of anyone who is worrying about this new metadata that has started showing up in their orgs.
What is “flowAccesses” for?
NOTE: Gearset’s comparisons have had an upgrade! We’re in the process of updating all our blog posts with the new UI images, but in the meantime you can find out more here.
Our users first noticed flowAccesses showing up in their org comparisons and nightly snapshots of their orgs’ metadata. Using Gearset’s diff viewer to compare the XML of two Salesforce orgs, they could see that it was a subcomponent of the Profile component. An apparent and unrecognized change to all of the Profiles in an org is obviously concerning. So they asked us to investigate.
The biggest clue was in the name. We knew we were looking for new Salesforce metadata that related to flows and had something to do with access. And there is a new feature in Salesforce that fits the bill: the ability to configure users’ access to run flows. Joining the dots, we’re confident that flowAccesses must be metadata relating to this feature. Unlike the permissions Run Flows, Manage Flows and Flow User, which allow users to run all flows, flowAccesses seems to be the metadata that allows you to choose exactly which flows your users can or can’t run, by restricting access to certain flows.
How is the subcomponent “flowAccesses” retrieved?
The only other evidence we have about flowAccesses is the behavior of Salesforce’s metadata API. We’ve discovered that to retrieve flowAccesses, you need to include the metadata types Profile and Flow definition in Gearset’s metadata filter. You also need to use version 47 of the metadata API, or later, which is a bit strange because the Flow definition metadata type was deprecated in version 44 of the API… 🤔 We haven’t yet worked out what’s going on there.
Keep an eye out for the Salesforce release notes which should bring more information in due course. In the meantime, if you’re looking to deploy flowAccesses, you can retrieve it with the filtering we’ve described above. Be aware that you’ll need to have the relevant FlowDefinition in the target environment, or deploy it with the flowAccesses. If you want to stop flowAccesses from showing up in your Gearset comparisons, removing flow definitions from the metadata filter is the best option.
Deploy flows and flow permissions painlessly
Flows, profiles and permissions can all be tricky to be deploy. To find out more about how Gearset makes deploying these metadata types painless, read our guide on deploying Flows. Or try it for yourself on a free trial!
