I've hit a bit of a snag and could use some insights.

The Core Issue So, I've been working on this 2G managed package (API version 59) and finally got it released and installed in the production Org. It's got 7 flows in total - 2 Screen Flows and 5 autolaunched ones. The catch? Only the first two (both record-triggered autolaunched flows) are working right in production.

Suspected Culprit: Permissions I'm thinking this might be a permissions issue. In my package, I set up two permission sets: 'Sales_Person' and 'System_Admin'. Both have the 'Run Flows' option ticked in the Flow and Flow Orchestration section. But here's the twist - I originally forgot to check this option in the initial versions. Even after fixing this in newer versions, the permission sets don’t seem to update post-installation. My temporary fix was creating a new set, 'System_Admin_2', and manually adding permissions. But no dice - the other 5 flows still won’t run.

Deployment Details A bit more on the deployment side: Following Salesforce's guidelines (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm#md_flow_upgrade), I axed the FlowDefinitions directory before creating the package. This solved some initial errors, but here’s the thing - the working flows are pretty basic, just copying text fields based on a user action. The more complex ones, especially dealing with M-D objects, are the ones giving me headaches.

Field-Level Security Concerns I also noticed some of the custom fields these non-functioning flows reference had their 'field level security' visibility turned off. I've corrected most of them, but maybe I missed a few? Is there a more efficient way to double-check the visibility of all fields?

Any tips or advice would be massively appreciated. Thanks a bunch!

1 Answer 1


Update: Issue solved!

Turns out, Flows can be kinda quirky with how they handle Namespace prefixes. It's a bit inconsistent: sometimes you need the prefix, other times, not so much. This totally explains why some of my Flows were chill after deployment, while others were throwing a fit. Here's the lowdown on what I had to do:

$Record References Need Prefixes: Whenever you're using $Record, tag on that prefix. Like this: $Record.namespace__Field_Name__c. And it’s the same deal with custom relationship retrievals, for example: $Record.namespace__Field__Name__r.namespace__Field_Name__c.

Handling Related Records: For related records, you’d do something like $Record.namespace__Field_Name__r.LastModifiedDate.

Get Records through a Variable: If you're pulling records through a variable, like var_Get_Record.namespace_Field_Name__c, make sure that namespace is there.

Standard System Fields are Cool Without It: No namespace needed for standard system fields. $Record.LastModified works just fine on its own.

Filters Seem to Be Laid-back About It: In my filters, I didn’t need the namespace. So, something like <field>Quoted_Amount__c</field> worked just fine.

It was very time consuming!

I welcome any good way of automating this stuff. Any ideas?

  • 1
    Develop your flow on a namespaced scratch org using sfdx best practice and you will find the flow editor does it all for you.
    – Phil W
    Dec 3, 2023 at 7:26
  • 1
    BTW, standard fields never require a namespace even on custom objects, simply because they are standard. Indeed, I believe they would not work with a namespace prefix since that would be referencing a non-existent field.
    – Phil W
    Dec 3, 2023 at 7:28
  • As you probably discovered, this is already mentioned here. The problem applies to 1GP and 2GP managed packages as well as unlocked 2GPs.
    – Phil W
    Dec 3, 2023 at 7:30
  • BTW, the fact we didn't suggest a reason probably comes down to the fact you simply said "some... do not work" and you did not include detail about any errors or specific behaviours observed - the question was actually too vague. It is always best to include exact error messages or some detailed explanation of observed behaviour.
    – Phil W
    Dec 3, 2023 at 7:35
  • Thank you Phil. So, from what you explained. Once I have my Metadata ready for testing and create a scratch org to test it, I should assign a namespace to that scratch so that it will add the prefix to it because that deployment was not in a managed package? Then, I can download the re-edited flows to my local project, sync it to my Repo and then create the managed package? By the way, the main reason I did not share errors was because I was NOT getting any errors at all.
    – cpaesano
    Dec 3, 2023 at 20:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .