#Flow163 discutindo

Hi, see the tool tip on the Recipient Addresses field which says it needs to have an email address not id. Try using the hardcoded email address and test to see its working.

Jordan, if there’s no component-visibility filter, I’d check the Guest User Profile permissions and how the button itself is configured.

Since the flow already runs in System Context Without Sharing, the execution mode probably isn’t why the button is missing. I’d compare the guest user’s access to the object, Apex classes (if used), and the Experience Cloud page.

Also check whether these are Dynamic Actions rather than an Experience Builder Flow component, since their visibility can be controlled separately.

As a quick test, try adding the same flow through the standard Flow component and view the page while logged out. If that works, the issue is likely with the button/action configuration rather than the flow itself.

Do the same sports always go down the same decision paths? If so I'd write a formula with case function, something like:

CASE(record.sport,

'Basketball',1,

'cricket',1,

'cow tipping',2,

'football, 2,

3)

Then the decision element you just have different paths for value 1,2,3 etc

Hi Mark - 'runs clean but zero rows' almost always means the Create IS failing and the error is being swallowed. Two fast moves to expose it: 

1. Add a Fault Path to your Create Records element (drag from the red node) and route it to a Screen showing {!$Flow.FaultMessage}, or run Flow Debug with 'Show query and DML details' ticked. Debug prints the collection size going INTO the create and how many rows it inserted - that instantly tells you whether the collection is empty or the records are invalid. 

The most common silent-zero with your exact pattern: 

2. The records in colRSSA carry an Id. For an INSERT the record vars must have NO Id - if your Assignment copies a source Retail Store record (which brings its Id along) instead of building a fresh record, the create no-ops. Build a NEW record variable with only the fields you set, no Id. 

Also check: 

- Create Records set to 'Multiple' from the COLLECTION (colRSSA), not 'One' from the single var. If debug shows colRSSA empty, your add-to-collection Assignment is the culprit - it must use the Add operator with colRSSA as the target. 

- Run the subflow in System Context (Without Sharing) if the running user may lack Create on Retail Store - DML silently no-ops in user context. 

- Any required field beyond the lookup fails the row; the fault message names it. 

Clean pattern: Loop > Assignment (set fields on a fresh record var, no Id) > Assignment (Add var to colRSSA) > after the loop, Create Records (Multiple, from colRSSA). 

Hope that unblocks it 🙂

Hi Carolyn - the catch is that RecordType is metadata every user can read, so a Get Records or Record Choice Set on RecordType always returns them all, regardless of who is assigned. There is no native 'filter record types by assignment' in Flow. Two routes that need no Apex you write or maintain: 

1. UnofficialSF's 'User-Aware Record Type Picker for Flows' - a free installable screen component built for exactly this; it shows only the record types the running user is actually assigned. Cleanest option if you are OK installing a component. 

2. Pure-native with Custom Permissions - create one Custom Permission per opportunity record type (or per group), assign each on the same permission set that grants that record type, then set each choice's component visibility (or a Decision) on the running user having that permission via Permission.YourCustomPermission. 100% declarative; the trade-off is you maintain the mapping, so it fits best when the record-type count is small. 

Tip: also run the screen flow in User Mode so field/record access is enforced - just note User Mode will not filter the record-type list itself, since that is assignment, not record access. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

Hi Team,

I faced the same issue and found a solution that worked for me.

My requirement was to link a newly created Messaging Session to the Case from which the session was initiated using a Screen Flow.

Solution:

Enable Change Data Capture (CDC) for the Messaging Session object in Setup. This publishes a change event whenever an action occurs on a Messaging Session record, such as create, update, or delete. The event message provides the Messaging Session record ID and its field values, including the Messaging User ID.

First, store the Case ID on the Messaging User record within the Screen Flow (or from wherever you are initiating the Messaging Session).

Since a Messaging Session change event is published whenever an event occurs on the record, subscribe to it using either a Platform Event-Triggered Flow or an Apex Trigger on the Messaging Session Change Event. Then perform the required logic:

1. Retrieve the Messaging User ID from the Messaging Session event.
2. Use the Messaging User record to get the Case ID that was stored earlier.
3. Update the Messaging Session record using the Messaging Session ID received in the event and the Case ID which we get by query the messaging user.

This will successfully link the Messaging Session to the Case.

If you need code samples or additional guidance for implementing this solution, please reply to this comment. 

Thanks.

Hey A. Bilgic, 

Per Salesforce's own Get Records documentation, when you retrieve a single record, the flow stores it as a Record (single) variable, and you can reference any field on it later using dot notation (e.g., YourContactVar.Email, YourContactVar.FirstName), without copying values into separate individual variables first. 

For your "Continue with existing Contact" path specifically: 

1. After the Decision element splits into your two paths, for the "Continue as-is" path, just don't add an Update Records element at all, if you never call Update Records, the Contact record in the database is never touched 

2. For anything downstream that needs Contact details (like a Create Records for a related object, or a merge field on a confirmation screen), reference the fields directly off your original Get Records variable using dot notation, e.g., {!Get_Contact.Id}, {!Get_Contact.Email} 

3. If you need to show the existing values on a screen (read-only, just for confirmation) without letting the user edit them, use a Display Text component and merge in the fields with dot notation, rather than using editable Record Fields (which are what create the "must be saved via Update Records" pattern) 

The key distinction: adding record fields to a screen for editing requires Update Records to persist changes, but simply referencing the Record variable's fields via dot notation elsewhere in the flow (Create Records, Decision conditions, Display Text, etc.) never touches the database, it's purely in-memory for the duration of the flow run. 

So the short answer: keep using the single Get_Contact record variable you already have, reference fields off it directly wherever needed downstream, and just skip Update Records entirely on the "continue as-is" branch. 

Reference: