Overview
This rule flags Salesforce Flows that do not have any associated test coverage. While Flows are powerful tools for automating business processes, they must be verified through dedicated test cases created within the Flow Builder's testing capabilities to ensure they behave as expected. Untested Flows, particularly those critical to business operations or invoked in complex scenarios, pose a significant risk.
Clayton classifies this as a Warning because untested Flows might still function in production, but without proper validation, they are highly prone to errors, regressions, and unexpected behavior during deployments, or as data and requirements evolve.
Manually testing your Salesforce Flows often misses crucial scenarios. This is where Flow Tests come in. They let you build comprehensive tests declaratively, so you don't need any development or coding skills. Just like with Apex, setting assertions in your Flow Tests is incredibly valuable. A particularly useful assertion is confirming whether a specific Flow element was executed, ensuring your logic flows exactly as intended.
Why Untested Flows Are a Risk
Untested Flows can lead to significant problems down the line, much like untested code. Here's why they're a concern:
Silent Failures: Without tests, Flows aren't protected from changes to your data model, inputs, or underlying logic. This can lead to unexpected, silent failures when configurations shift.
Business Impact: Flawed Flows can cause runtime errors or incorrect data manipulation, directly impacting your business processes and data integrity.
Eroding Trust: If your Flows aren't rigorously tested, it reduces confidence in your entire automation stack. It becomes harder to trust their behavior, especially during org changes or updates.
Difficult Debugging: Issues might only surface in production, affecting users before you even know there's a problem. Catching these early in development through testing saves a lot of headaches.
Increased Regressions: New changes can inadvertently break existing Flow functionality if you don't have tests to catch these regressions.
Lack of Documentation: Well-defined Flow Tests act as clear documentation of your Flow's expected behavior, something manual testing rarely provides.
Ultimately, proper test coverage makes your Flows resilient, scalable, and reliable, just like well-tested Apex code.
Proper test coverage ensures Flows are resilient, scalable, and reliable, just like well-tested Apex code.
What Triggers This Rule
This rule flags Salesforce Flows that do not have an associated Flow Test. In the context of Salesforce, a "Flow Test" refers to the declarative test cases created directly within the Flow Builder's "Test" tab, designed to validate a Flow's behavior. The rule checks for the existence of a corresponding Flow Test file (.flowtest-meta.xml) that explicitly targets the Flow in question.
Recommended Approach
Utilize the declarative testing features directly within the Flow Builder to create and run test cases for your Flows. This involves defining:
Test Inputs: Set up the records and variable values that simulate the Flow's starting conditions.
Expected Outcomes: Define the specific record changes, variable assignments, and error conditions that the Flow should produce.
Assertions: The Flow test tool allows you to assert that certain field values change as expected, records are created/updated/deleted, or specific fault paths are taken.
Best Practice Example
Imagine a record-triggered Flow named Update_Case_Status that closes a Case when a related Task is marked 'Completed'.
To test this declaratively in Flow Builder:
Create a New Test: Go to the "Test" tab in Flow Builder for
Update_Case_Status.Define Test Inputs:
Set the trigger to
After Save.Create a test
Caserecord (e.g., Status = 'Open').Create a test
Taskrecord, associated with the test Case, and set its Status to 'Completed'. This simulates the DML that triggers the Flow.
Set Expected Outcomes (Assertions):
Assert that the
Caserecord'sStatusfield on the updated test Case isClosed.Assert that no errors occur (i.e., the Flow follows the success path).
Run the Test: Execute the test case and verify it passes.
This ensures the Flow's logic is validated under controlled conditions. For more complex scenarios or when Flow is part of a larger Apex-driven transaction, Apex tests can still be used to invoke and verify the overall transaction behavior that includes the Flow, but the Flow's internal logic should first be tested declaratively.
Summary
Flows without dedicated tests are fragile and introduce significant risk to your Salesforce automation. Leveraging the declarative testing capabilities within the Flow Builder is essential to ensure reliability, prevent regressions, and catch issues early. Clayton flags untested Flows as a Warning to help teams enforce test discipline and build a robust, trustworthy declarative automation layer.