03.04.03 — State Transition Testing: Flows and Status-Driven Objects
Lesson goal
This lesson explains how to apply State Transition Testing to Salesforce objects and processes that are driven by statuses and automation.
After this lesson, you should be able to:
- identify states and transitions in Salesforce processes,
- design test cases that validate allowed and disallowed transitions,
- detect defects caused by incomplete or inconsistent automation logic.
Why state transitions matter in Salesforce
Many Salesforce business processes are state-driven.
Examples include:
- Opportunity stages,
- Case statuses,
- Approval process states,
- Custom lifecycle fields.
State changes often:
- trigger automation,
- enable or disable actions,
- lock or unlock records,
- change permissions or visibility.
Testing only final outcomes ignores critical behavior between states.
What State Transition Testing really is
State Transition Testing focuses on:
- the states a record can be in,
- the transitions allowed between those states,
- the system behavior during each transition.
Instead of asking:
“Does the record work?”
It asks:
“What states exist, and how can the record move between them?”
Identifying states in Salesforce
States are usually represented by:
- picklist values,
- status fields,
- record lifecycle flags.
For example, an Opportunity may have states such as:
- Prospecting
- Qualification
- Proposal
- Closed Won
- Closed Lost
Each state represents a distinct behavior context.
Identifying transitions
Transitions define how a record can move from one state to another.
Examples:
- allowed transitions (Qualification → Proposal),
- disallowed transitions (Closed Won → Prospecting),
- conditional transitions (require approval or validation).
Transitions may be controlled by:
- validation rules,
- flows,
- approval processes,
- Apex logic.
Testing allowed transitions
For each allowed transition, test cases should verify:
- that the transition is possible,
- that required conditions are enforced,
- that automation executes correctly.
Expected Results should confirm:
- the new state,
- triggered automation outcomes,
- side effects (field updates, notifications, record locks).
Testing disallowed transitions
Disallowed transitions are often more important than allowed ones.
Test cases should verify:
- that invalid transitions are blocked,
- that meaningful errors are shown,
- that record state remains unchanged.
Many production defects appear when:
- transitions are partially blocked,
- automation executes before validation,
- side effects occur despite failure.
Flows as state transition controllers
Flows frequently control state transitions in Salesforce.
They may:
- react to field changes,
- enforce conditional logic,
- trigger updates or integrations.
When testing flows:
- identify entry conditions,
- map decision branches,
- verify outcomes for each path.
Flows often hide complex transition logic behind simple UI actions.
Record locking and irreversible states
Some states are irreversible.
Examples:
- Closed Won Opportunities,
- Approved records,
- Archived Cases.
Test cases should verify:
- that irreversible transitions cannot be undone,
- that editing restrictions are enforced,
- that permissions do not bypass locks.
These are high-risk areas for defects.
Combining state transitions with Preconditions
State Transition Testing depends heavily on Preconditions.
Preconditions should define:
- initial record state,
- required related data,
- user permissions.
Without explicit Preconditions:
- transitions become ambiguous,
- failures are hard to diagnose,
- execution results vary.
Common state transition testing mistakes
Frequent issues include:
- testing only happy paths,
- ignoring reverse or skip transitions,
- assuming automation order,
- missing permission-dependent transitions.
Each of these reduces coverage of real-world behavior.
Practical guideline
When designing Salesforce test cases:
- list all relevant states,
- list allowed and disallowed transitions,
- test both positive and negative paths,
- verify side effects and locks.
State Transition Testing reveals defects that other techniques miss.
Key takeaway
- Salesforce processes are often state-driven.
- Testing only final states is not enough.
- State Transition Testing validates how records move through their lifecycle.
- Flows and automation make transition testing critical.
Understanding states and transitions is essential for reliable Salesforce QA.