Some flows not working on 2G managed package in Production Org

Question

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!

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?