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,
Two separate root causes here, both well-documented, and both explain your exact symptom (works as admin in Debug, silently does nothing for guest users on the live site).
1. Record creation not happening: most likely the flow isn't actually enabled for the Guest User profile, even if it "worked" in Debug.
Profile-level object permissions (Read/Create on Application) are necessary but not sufficient. You also need to explicitly grant the flow itself to guest users, this is a separate step from object permissions:
- Experience Builder > Settings (gear icon) > General tab > confirm "Guest users can see and interact with the site without logging in" is checked, then click the guest user profile link.
- Under Enabled Flow Access, click Edit, and confirm your Transitional Coach Application flow is moved into the Enabled Flows column (not just present in the Available list).
Reference:
https://help.salesforce.com/s/articleView?id=experience.rss_flow_guestuser.htm&type=5This is the single most common cause of "works when I test it logged in, does nothing for actual guest visitors", the flow needs this explicit enablement separate from object CRUD permissions.
2. Emails not sending: this is a hard platform restriction, not a config you're missing.
As of Spring '23, Salesforce permanently removed the "Send Email" system permission from the Guest User profile across ALL orgs, and since permission sets can't be assigned to guest users either, there is no way to grant this back declaratively. This is intentional (anti-spam/abuse prevention for public-facing guest contexts), not a bug.
Workaround: don't send the email directly from the guest-context flow. Instead:
- Have the guest flow create the Application record only.
- Use a separate Record-Triggered Flow on the Application object (After Save), running as an internal/system context, not the guest user, to send the confirmation email. Since this second flow runs on the object trigger rather than in the guest user's session, it isn't restricted by the Guest User "Send Email" removal.
Given your record creation is also failing (not just email), I'd fix #1 first, that's likely blocking everything, and once records start getting created successfully, wiring up a Record-Triggered Flow for the email (per #2) will resolve the email gap cleanly without depending on guest user email permissions at all.
