#Flow151 debatiendo

Hi @Rohit .

I would use an After-Save Record-Triggered Flow on the Employee object, since the automation needs to create/update related records and perform actions. 

Flow Design: 

 Employee Created → Create User → Assign Permission Set → Create Onboarding Tasks → Send Welcome Email 

Why After-Save? Creating a User, assigning a Permission Set, creating Tasks, and sending notifications are actions that should happen after the Employee record is saved. Salesforce also documents Flow-based automation for assigning permission sets to users.  

Failure Handling: Add Fault Paths to the important Create/Action elements and route errors to an error-handling path (for example, log the error and notify an admin). Also check prerequisites such as duplicate Permission Set Assignment before assigning it.  

 Make sure the Flow's execution context and permissions are appropriate for the operations it performs.  

This keeps the onboarding process automated, maintainable, and easy to troubleshoot.  

Hope This Helps!!

@Himanshu Shekhar

I put:  

Content Document ID= File Upload > Related Record ID but it's not working and I can't find Title like you mentioned.  

Also, if I don't do the loop and if the partner submits 2 more more attachments, will it just capture one documents' name?  If so, that's still perfect.  This File Name field will populate into another related object's text field.  

Resolved. 

Issue was similar to: 

Flows assignment elements throws error with field __NotFound References after 258 release | Issue Details | Salesforce Help

In my case, selectedRows from data table could not be used directly. 

I created variable to store collection of selected apex-defined variables. 

In data table's advanced settings I selected 'Manually assign variables (advanced)' and mapped selected rows to new variable. 

That resolved the problem.

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

 This is a great real-time Salesforce Flow scenario. It covers key concepts such as 

Subflows, Decisions, Loops, Scheduled Paths, Fault Connectors, Tasks, and Email Notifications. A very good assignment for practicing end-to-end Flow automation.  

Possible Flow approach: 

Record-Triggered Flow (Claim – After Save) → Call Fraud Detection Subflow → Decision for Fraud Score/Claim Type → Create Investigation and assign Investigator → Create follow-up Task → Get Related Documents + Loop to identify missing documents → Create “Upload Missing Documents” Task → Update Priority to Critical if Claim Amount > $100K → Update Approval Status based on Approval Stage → Scheduled Path (48 hours) for escalation → Configure required Email Alerts → Add Fault Connectors for Task creation and log errors in an Error Log

 record, with an admin notification. 

This approach keeps the automation modular, scalable, and easier to maintain.  

Hope this Helps!!

Hi Eeswarini, 

Since this worked before Winter '27 in the same design, this looks like a genuine regression in how the flow's finish behavior is being handled after the release — not a logic error in your flow. 

Background: "YOUR FLOW FINISHED" appears whenever a flow ends without a screen as its last executed element. If your flow's last step is an action (like ShowToast) rather than a screen, Salesforce falls back to this default finish screen. If this wasn't happening before Winter '27 with the exact same flow, something changed in how the platform determines "last executed element" or how quick-action-launched flows auto-close. 

Fixes to try: 

1. Add a final Screen element at the very end (after ShowToast), with header and footer removed, and use a Navigation-type action (e.g., NavigateToNext or similar Unofficial SF flow action) to auto-continue/close instead of a real screen the user sees. This is the standard workaround regardless of the regression, since it forces flow completion via a screen node rather than relying on default finish behavior. 

2. Check the Quick Action's flow settings on the record page — Winter '27 changed some Flow/Quick Action finish-behavior defaults; confirm "Reload page after finishing" or the flow's finish handler config still matches your prior sandbox setup. 

3. Compare flow versions/metadata between the working sandbox and the affected environment — if this environment got the Winter '27 upgrade first, check if a newer flow runtime setting differs. 

Given it's release-tied and reproducible, I'd also open a case referencing "screen flow finish behavior change post-Winter '27" — if this is a genuine platform regression, Salesforce needs it logged to fix it broadly, not just worked around per-flow. 

Reference: