04.03.04 — Order of Execution and Automation Interaction

Lesson goal

This lesson explains why the Salesforce Order of Execution (OOE) is critical for QA and how automation components interact during record save operations.

After completing this lesson, you should be able to:

• understand how Salesforce processes a record save step by step
• identify high-risk interaction points between Flows, Apex, and Validation Rules
• design test cases that expose race conditions, recursion, and data overwrites
• validate rollback behavior and integration payload correctness

This lesson completes the Automation Testing section of Module 4.

The problem: the unseen flow of data

Salesforce does not execute automation randomly.

Every record save follows a strict Order of Execution, defining when:

• Validation Rules run
• Before-Save and After-Save Flows execute
• Apex Triggers fire
• Roll-Up Summary Fields recalculate
• Integrations and outbound actions occur

If QA ignores execution order, serious defects can slip through:

• one automation overwrites another
• recursion causes governor limit failures
• integrations receive incomplete or incorrect data
• validation occurs too late to protect data integrity

Order of Execution testing shifts QA focus from components to interactions.

Order of Execution as a testing concept

From a QA perspective, Order of Execution answers one question:

Which automation wins when multiple components touch the same data?

OOE testing is not about memorizing step numbers.
It is about validating precedence, timing, and side effects.

Before-save logic: validation and pre-processing

Before-save logic prepares data before it is committed to the database.

This phase includes:

• Validation Rules
• Before-Save Flows (Fast Field Updates)
• Apex before insert / before update triggers

Validation Rules vs automation

Validation Rules must block invalid data before automation modifies it.

Test focus:

• attempt to save data that violates a Validation Rule
• ensure the save fails immediately
• confirm no automation changes are applied

If automation bypasses validation, data integrity is compromised.

Before-Save Flow vs Apex trigger

Both Before-Save Flows and Apex Before Triggers can modify the same field.

Test focus:

• trigger both automations
• verify which one sets the final value
• confirm the result matches expected execution precedence

Unexpected final values indicate automation conflicts.

After-save logic: side effects and dependencies

After-save logic runs once the record is committed.

This phase is used for:

• cross-object updates
• roll-up calculations
• notifications
• integration preparation

Roll-Up Summary interaction

Roll-Up Summary Fields recalculate before After-Save Flows.

Test focus:

• update a child record
• verify the Roll-Up value is recalculated
• confirm the After-Save Flow reads the updated value

If the Flow reads stale data, execution order assumptions are wrong.

External integrations and final data state

Integrations execute very late in the Order of Execution.

They must receive:

• fully validated data
• final values after all automation
• consistent, committed state

Integration payload test

Test focus:

• trigger an integration callout
• capture the outbound payload
• verify all calculated fields are final and correct

If the payload reflects intermediate values, integration timing is incorrect.

Recursion and automation loops

Recursion occurs when automation updates a record in a way that retriggers itself.

This is one of the most dangerous Salesforce failures.

Recursion test

• perform a bulk update using Data Loader
• trigger automation that modifies the same record
• observe transaction behavior

Expected result:

• transaction completes successfully
• no governor limit or stack depth errors

Failures indicate missing recursion guards or non-bulkified logic.

Transaction rollback across execution phases

The Order of Execution runs inside a single transaction until external actions occur.

Rollback integrity test

Scenario:

• Before-Save Flow updates Field A
• After-Save Apex Trigger throws an error

Expected result:

• Field A reverts to its original value
• no partial data persists

If earlier changes remain, rollback integrity is broken.

Practical QA strategies

Test interactions, not components

Avoid testing Flows, Apex, and Validation Rules in isolation.

Instead:

• design tests that trigger multiple automation layers together
• validate final data state, not intermediate steps

Bulk testing is mandatory

Automation that works for one record may fail for many.

Always include:

• mass insert
• mass update
• mixed-state record batches

Summary

The Salesforce Order of Execution defines how automation truly behaves, not how it appears in Setup.

From a QA perspective:

• execution order determines which logic wins
• interaction defects are higher risk than isolated failures
• recursion and rollback issues only surface under realistic conditions

By testing automation interactions at key execution points, QA ensures stability, predictability, and data integrity across the entire Salesforce platform.

What’s next

In the next lesson, we move from automation mechanics to system limits and scale:
04.04.01 — Governor Limits, Bulkification, and Performance Risk