#Flow167 人正在讨论

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.

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 :)

Hey Thomas, I agree with your understanding. As a best practice, I agree that specifying the object up front in the entry conditions of the scheduled flow is the way to go, especially for bulkfication. I know there can be some confusion where admins will set a very generic entry criteria for the scheduled flow, and then use a get records inside the scheduled flow to drilldown to the records they want, but in my opinion, this can degrade performance as it's executing this get records for every iteration of the initial collection of records that met the criteria. It's usually more effective to have your entry criteria essentially be your Get Records element so that everything you need to gather upfront is already collected.    I liken using a Get Records inside a Scheduled Flow similar to using a Get Records inside a Flow Loop. It's not recommended because you can easily hit governor limits (although sometimes it is needed for complex scenarios)

Hey Keshav, 

This is a known Rich-Text-Formatted Body mismatch, your Body input is being fed rich text content, but the action isn't set to render it as HTML, so it shows the raw <p> tags instead of formatted text. 

Fix in your Flow's Send Email action: 

1. Find the Body/Text Template resource you're using 

2. If your Text Template resource is set to Rich Text, you must also set Rich-Text-Formatted Body = True on the Send Email action, this tells Salesforce to render the HTML instead of showing it as plain text 

3. If you don't need formatting at all, switch the Text Template to Plain Text instead, mixing Rich Text content with a Plain Text body setting is exactly what produces raw tags like <p>...</p> in the email 

Also, since your screenshot shows Gmail flagging this as spam, that's a separate issue, likely caused by using a Trailhead Playground's default noreply/

sending domain without proper SPF/DKIM setup, not related to the HTML tag issue. 

Reference:

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