I need help troubleshooting a public Experience Cloud Flow for a Transitional Coach Application. The Flow works in Debug mode: it creates an Application record and sends an email. However, when I submit it through the published site in an incognito/private browser, it reaches the end but does not create the record or send the email.
The site has a Guest User profile named “Transitional Coach Application Profile,” and Read/Create are enabled on the Application object. I need someone to identify the guest-user/Flow-context issue and help me test the fix. I can share screenshots and grant supervised screen-share access. Thanks
#Salesforce_developer #Beginner Developer #Salesforce Developer #Developers Edition
Hi @CM Seb
Since the Flow works correctly in Debug but fails when submitted from the Experience Cloud site in an Incognito/Private browser, the first thing I would check is the Guest User context. Debugging as an admin/user does not necessarily reproduce the permissions and execution context of the Experience Cloud Guest User.
I would troubleshoot it in this order:
1. Check Guest User permissions
Make sure the Guest User profile has the required Create/Read access on the Application object and, importantly, Field-Level Security for every field that the Flow is trying to populate. Object-level Create permission alone is not sufficient.
2. Check how the Flow runs
In Flow Builder, review How to Run the Flow. If appropriate for this use case, consider running the necessary data operations in the supported System Context so the Flow isn't unnecessarily restricted by the Guest User's record-level access. However, don't use elevated context as a substitute for properly securing the Flow—only expose the data/actions the guest actually needs.
3. Check the owner of the Application record
Guest Users have restrictions around record ownership. For records created by Experience Cloud Guest Users, configure a default owner for guest-created records under the Experience/Digital Experience settings. This is especially important if the Application record cannot be owned directly by the Guest User.
4. Add Fault paths
Add a Fault connector to the Create Records element and any other important DML/action elements. Connect it to a Screen or other error-handling path and display/log the Flow's $Flow.FaultMessage. This will tell you whether the actual problem is permissions, required fields, validation rules, ownership, or another Flow error.
5. Check the Send Email step separately
Since the Flow performs both record creation and email sending, test these two operations independently. Experience Cloud Guest Users have additional restrictions around email and access, so the email action may require a different approach or execution context.
6. Check Debug Logs
If possible, enable a trace/debug log for the user/context executing the site Flow and reproduce the issue from the Experience Cloud site. This is much more reliable than debugging the Flow as an administrator.
Most likely cause: the Flow is being tested as an admin in Debug, while the live Experience Cloud submission is running as the Guest User, so a permission/FLS/ownership restriction is being encountered.
Hope This Helps!!
