Building Secure Screen Flows For External User Access
Screen Flows provide interactive data collection and display in Salesforce, but when exposed to external users via Experience Cloud sites, security risks can arise—especially when flows run in system context and retrieve all fields automatically. This can unintentionally expose sensitive data in the user's browser that malicious actors might access or manipulate. By using system context sparingly, carefully defining external user permissions, specifying only necessary fields in Get Records, and leveraging elevated-access subflows instead of elevating the entire flow, developers and architects can build secure, performant screen flows for external user access. Additionally, careful handling of screen actions and outputs prevents unintended data exposure or tampering in the client side.
- Avoid running entire screen flows in system context for external users.
- Specify only needed fields in Get Records elements to limit data exposure.
- Use subflows with elevated access instead of elevating parent flows.
- Sanitize and limit record collections before performing DML updates from client inputs.
- Never pass sensitive info in inputs or outputs of screen actions visible in client.
A diagram explaining the client and server data exchange that occurs within a Screen Flow embedded within an Experience Cloud site Screen Flows are an important part of any implementer’s toolset when building forms within Salesforce. A screen flow is a flow type that requires user interaction as it includes screens, local actions, steps, choices, or dynamic choices. Fundamentally you can use a screen flow to collect data or display data to users. But like anything built using Well-Architected guidance, ensuring the security of your solution is the first priority. If your Screen Flows are not built with security in mind, you may be unintentionally exposing fields and data. This is especially true when providing an external user access to that screen flow on an Experience Cloud site. Within the Well-Architected Framework we provide specific guidance to not mix system and user context data operations in the same transaction within any automation.