You are here:
Data Safety When Running Screen and Autolaunched Flows in System Context
Screen flows and autolaunched flows without triggers can expose more data than intended. This potential issue primarily affects Experience Cloud sites accessed by external users. Configure proper user permissions for field-level and record-level security instead of running flows in system context. When system context is necessary, use only the minimum fields and records required.
Required Editions
| View supported editions. |
To control what data your users can access, follow these guidelines and suggested workarounds.
Restrict User Access to Data in Screen Flows
Run screen flows in user context whenever possible, because it enforces permissions that restrict user access to data. When you run a screen flow in system context, especially system context without sharing, it doesn’t enforce permissions for users, increasing the chance of unintended data sharing. There are other, safer ways to grant access to users than running a flow in system context.
Instead of setting the entire screen flow to run in system context, use the Subflow element to launch a flow that performs actions that require permissions beyond what the running user has.
Store Specific Fields in Get Records Elements
When you override an autolaunched flow (no trigger) or screen flow to run in system context, and use a Get Records element to pass records into a screen component, action, or another flow, specify which fields to store by selecting Choose fields and let Salesforce do the rest instead of selecting Automatically store all fields. If you pass in the entire record variable or record collection from a Get Records element to a screen component, an action, or another flow, the flow doesn’t know which fields are needed, so it retrieves all the fields the user can access. When you select Choose fields and let Salesforce do the rest and specify fields, Salesforce stores only the fields you need, reducing the number of fields that are exposed to users.
Specify Fields and Records in Flows on Experience Cloud Sites
When you run in system context and use a Create Records, Update Records, or Delete Records element in a screen flow on an Experience Cloud site, limit the number of fields and records to only those that you intend the user to edit.
- For Create Records elements, for How to set record field values, select Manually and specify each field to use when creating the record.
- For Update Records elements, for How to Find Records and Set Their Values, select Specify conditions to identify records, and set fields individually. Use filter conditions to find the records to update and then specify the fields to update.
- For Delete Records elements, for How to Find Records to Delete, select Specify conditions and use filter conditions to find the records to delete.
If you must use a record variable or record collection in a Create Records, Update Records, or Delete Records element, use a Transform element first to filter out fields that you don’t want edited. See Transform Data in a Flow. Then, in a Create Records, Update Records, or Delete Records element, select the record variable or record collection that the Transform element generates.
Considerations for Invoking Screen Actions
Keep these considerations in mind when you use an Action Button component to trigger a screen action or when you want to trigger a screen action automatically based on changes to the input values.
- Check the flow run context of an autolaunched flow that’s called by a screen action. The autolaunched flow can run in a different context than your screen flow, potentially exposing more data than you want. Consider keeping the autolaunched flow running in user context. If the autolaunched flow must run in system context, use the suggestions in the Restrict User Access to Data in Screen Flows, Store Specific Fields in Get Records Elements, and Specify Fields and Records in Flows on Experience Cloud Sites sections to modify the flow and keep your data safe.
- Use an autolaunched flow called by a screen action only to find data or perform calculations. If you must create, update, or delete records, use a Create Records, Update Records, or Delete Records element in the screen flow or use a different flow that’s launched by a Subflow element.
- Reference a screen action only in the screen element where the screen action is configured. If you must reference the screen action’s output somewhere else in the flow, run the screen action's autolaunched flow again in a Subflow element and reference the Subflow element’s outputs instead.
Check Inputs and Outputs of Flows Launched by Subflow Elements Running in System Context
Follow these guidelines when you configure a flow launched by a Subflow element that’s running in system context.
- Make variables available for input and output only if you plan to use them in the flow that launches the referenced flow. Unused input and output variables can expose users to unnecessary data.
- Avoid passing in inputs to a referenced flow that are easy to guess. For example, if you pass in the company email address of a record and the company email addresses follow the pattern firstname.lastname@company.com, it’s easy to guess another record’s email address and have access to that other record.
- Make sure a referenced flow includes only output values that are directly used in the flow that launched it. For example, if you need only a collection of contact record birthdays, don’t also return all information about the contacts or the contact's accounts.
