#Flows23 discutindo

Hello Amit, 

Yes, this can happen due to backend synchronization/caching. Newly created Flows may take a few minutes before they become available in the Reference Action dropdown for a subagent. It’s not usually an issue with the Flow itself. There doesn’t seem to be a fixed guaranteed propagation time, but in practice, waiting a few minutes and refreshing/reopening the action configuration usually makes the Flow appear. Hope this helps!

@Mario Santellan

your flow is basically right — the only broken piece is the GetFileName filter value. In that resource picker you're currently on 'Related Record ID', which is the record you attached the files to, not the uploaded file. Instead pick the Upload File component's 'Content Document IDs' output (Upload File > Content Document IDs) — that's the list of the uploaded files' Ids. Also change the operator from Equals to In, since that output is a collection: the condition should read Content Document ID In → Upload File > Content Document IDs. Equals against a collection is exactly why nothing matched. Your Title mapping is already right — Title lives on the ContentDocument record, which is why 'Content Document from GetFileName > Title' works in AddAttachmentName (Title = file name without the extension; add FileExtension if you need the .pdf/.docx part). On multiples: with 'Only the first record' selected you'll capture just the first file's name. If a partner uploads 2+ files and you want them all, switch GetFileName to 'All records', add a Loop over it, and in an Assignment append each 'Loop > Title' (plus a comma) into a Text variable, then map that variable into File Name. If one name is enough, first-record is perfect as-is. Give that a try — it should populate.

No, the Flow itself won't automatically restart just because Apex updates the same record — Salesforce doesn't loop back into the currently running Flow from within its own transaction. 

But watch out for this:

If that Apex update happens to match the entry criteria of a

One-line takeaway:

Same Flow instance won't re-run recursively, but a fresh Flow trigger can fire on that DML — so it's still safer to add a guard condition (like checking if the specific field actually changed) if you want to avoid unintended re-entry. 

Hi @Archana Chittoor

Yes, we can create a report to see the usage of Screen Flows.

Go to Reports -> Public Folders -> Sample Flow Report: Screen Flow.

This report shows:

• Which users are running the Screen Flows
• Number of flow executions
• Flow interview status
• Time users spend on each screen

By default, the report shows data from the last 7 days. We can change the date filter, but the maximum available data is 31 days.

If the report is not available, we can create a custom report type using Flow Interview Logs and Flow Interview Log Entries.

Thanks. 

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.

Hey Ramandra, 

Himanshu's answer is accurate and matches what's actually being reported. Real-world evidence backs this up: even after explicitly turning on "Allow OAuth Username-Password Flows," users are still getting a "Username-Password Flow Disabled" error, confirming the toggle alone doesn't guarantee the flow will work, Salesforce's platform-level retirement enforcement can override it regardless of your org setting. 

So to your three original questions: 

- The setting existing and being toggleable doesn't mean the flow will actually function, this is confirmed behavior people are hitting even now 

- Whether Support can override this for validation purposes is genuinely a case-by-case Support/AE conversation, not something the community can confirm 

- Not edition-specific, it's the platform-wide retirement, not a licensing tier restriction 

Practical suggestion: since you're already building the Client Credentials integration, validate it independently rather than trying to get the legacy flow re-enabled for a side-by-side. Compare against logs/behavior from your old integration instead of live-running both simultaneously, that avoids being blocked by something Salesforce is actively phasing out. 

Reference: