Overview
This rule identifies Flows that do not define any access restrictions, either by a profile or a permission set. As a best practice, Flows should be restricted to specific users or groups to control who can invoke them. Omitting these restrictions allows all users the possibility to launch a Flow, which is typically undesirable and can lead to unintended consequences or security vulnerabilities.
Clayton classifies this as a Warning because while it may not cause an immediate system crash, it creates an uncontrolled access point to automated processes, increasing security risks and potential misuse of functionality.
Why This Matters Missing access restrictions in Flows can lead to:
Unauthorized Invocation: Any user could potentially invoke the Flow, regardless of their role or need, leading to unintended data changes or process executions.
Security Exposures: If a Flow performs sensitive operations (e.g., updating critical data, making external callouts), unrestricted access could be exploited by malicious actors.
Data Integrity Risks: Unintended invocations can lead to corrupted or inconsistent data if the Flow is not designed for broad, unrestricted use.
Resource Consumption: Uncontrolled access can lead to excessive Flow executions, potentially consuming valuable governor limits and impacting overall org performance.
Compliance Gaps: Many regulatory frameworks require strict control over who can perform specific actions within a system. Omitting access restrictions can create compliance violations.
Confusion and Misuse: Users may unknowingly trigger Flows, leading to confusion about why certain actions occurred or data changed.
What Triggers This Rule
Clayton flags Flows that are deployed or active but do not have explicit access controls defined
Recommended Safeguards To restrict access to your Flows and ensure they are invoked only by authorized users:
Assign to Specific Profiles: For Flows that should only be accessible to users with certain baseline permissions, assign the Flow to relevant user profiles.
Utilize Permission Sets: For more granular control and flexibility, assign the Flow to specific permission sets. This allows you to grant access to a Flow without altering a user's entire profile. Permission sets are ideal for enabling users to access a Flow based on their job function or temporary needs.
Bundle with Permission Set Groups: Organize related permission sets into permission set groups to simplify administration and ensure users receive all necessary Flow and object permissions.
Implement Entry Criteria within the Flow: Even with profile/permission set restrictions, add entry criteria to the Flow itself to validate the running user or other conditions before critical actions are performed.
Consider System vs. User Context: Understand whether your Flow needs to run in the user's context (respecting their permissions) or the system's context (bypassing some permissions). While system context can be powerful, it requires careful security considerations. Flows invoked by a button, link, Visualforce, or Lightning page will run in the user context, while those invoked by another process will run in a system context.
Regular Access Reviews: Periodically review who has access to your Flows and whether those permissions are still appropriate.
Summary
Flows without defined access restrictions can be invoked by any user, leading to potential security exposures, data integrity risks, and compliance issues. Clayton flags this as a Warning to encourage that Flows be restricted to specific users or groups. As a best practice, Flows should be restricted to specific users. Omitting restrictions gives all users the possibility to invoke a flow, which is typically undesirable. Implementing access controls via profiles and permission sets is crucial for a secure and well-governed Salesforce environment.