04.03.01 — Flow Testing Fundamentals

Lesson goal

This lesson introduces structured testing of Salesforce Flows as declarative automation, treating them with the same rigor as custom code.

After completing this lesson, you should be able to:

• test when a Flow runs and when it must not run
• design test cases that cover all decision paths
• validate side effects across related records
• verify transaction integrity and rollback behavior

This lesson opens the Automation Testing section of Module 4.

The problem: Flows are the new code

Salesforce Flows have replaced legacy automation tools such as Workflow Rules and Process Builder.

Modern Flows:

• contain complex branching logic
• update multiple objects in a single transaction
• perform callouts and send notifications
• often replace Apex for business logic

From a QA perspective, this means Flows must be tested like code, not configuration.

Testing only CRUD outcomes is insufficient.
QA must validate:

• when the Flow executes
• which path it follows
• what side effects it produces
• how it behaves when something fails

Core areas of Flow testing

Effective Flow testing focuses on three areas:

1. entry conditions
2. decision logic
3. side effects and transaction management

Entry conditions and triggers

Entry conditions determine whether the Flow runs at all.
They are the first and most important test gate.

Create-triggered Flows

• Test focus: exclusion logic
• Action: create a record that does not meet entry criteria
• Expected result:
  Flow does not execute and no side effects occur

This test proves the Flow does not run accidentally.

Update-triggered Flows and ISCHANGED()

Update-triggered Flows frequently rely on ISCHANGED() conditions.

Test focus

• update the trigger field → Flow must execute
• update a non-trigger field → Flow must not execute

This test prevents performance issues and unintended automation loops.

Scheduled paths

Scheduled paths introduce time-based risk.

Test focus

• verify the Flow executes on the correct date
• confirm execution context (system vs record owner)
• test boundary dates

Boundary test:
Day N-1 → no execution
Day N → execution
Day N+1 → no duplicate execution

Decision paths and logic coverage

Every Decision element inside a Flow defines mandatory test cases.

QA must ensure:

• all paths are reachable
• default paths handle unexpected data
• boundary conditions behave correctly

Boundary value example

• condition: Amount > 100,000
• test cases:
• Amount = 100,001 → high-value path
• Amount = 100,000 → default or standard path

This validates operator correctness (> vs >=).

Default path testing

Always include at least one test that forces execution into the Default Outcome.

Default paths often hide:

• missing logic
• unhandled data states
• silent failures

Side effects and transaction management

Flows often modify data beyond the triggering record.

Cross-object updates

• Test focus: verify related records are updated correctly
• Example: updating Opportunity updates related Account data

External integrations

Flows that perform callouts must be tested for:

• success handling
• failure handling
• partial execution risk

If the external system fails, Salesforce data must remain consistent.

Notifications and alerts

• verify correct recipients
• verify correct content
• ensure notifications are not duplicated

Notification defects are common and often missed.

Transaction rollback behavior

Flows run inside a single transaction.

If any element fails:

• the entire transaction must roll back
• no partial updates are allowed

Rollback test

• Flow updates Record A successfully
• Flow fails on Record B due to Validation Rule
• Expected result:
  Record A remains unchanged

If partial updates persist, data integrity is broken.

Using the Flow Debug tool

The Flow Debug tool is essential for QA.

QA usage pattern

1. reproduce the issue in Debug mode
2. simulate boundary and negative inputs
3. observe which decision path was taken
4. identify the exact failure point

This enables precise defect reporting without trial-and-error testing.

Summary

Salesforce Flows must be tested as executable logic, not configuration.

From a QA perspective:

• entry conditions prevent unintended execution
• decision paths require full coverage
• side effects must be validated explicitly
• rollback behavior protects data integrity

Path-centric testing ensures Flows behave correctly, safely, and predictably in production.

What’s next

In the next lesson, we expand automation testing further:
04.03.02 — Error Handling, Fault Paths, and Defensive Flow Design