Flow: changes from this flow won't be saved because of the Save Order of Execution

Salesforce processes record saves in a defined order — the Save Order of Execution. Record-triggered flows fit into this order at one of two phases:

Pick wrong, the platform either rejects the action or silently drops the change.

Before-save: fast and cheap

Trigger condition: Account is created
Action: Set Account.Last_Synced__c = NOW()

This runs before the record hits the database. The platform applies your assignment as part of the save itself — no second DML, no extra governor limits used.

What before-save can do:

• Set fields on the same record (the record being saved)
• Use formulas to compute new values
• Read fields on the same record

What it can't do:

• Update related records (parents, children)
• Create new records of any type (other than the one being saved)
• Callouts
• Send emails

After-save: powerful but expensive

Trigger condition: Account is created
Action: Create a Contact for this Account, send email to Owner

This runs after the record is saved. The platform issues additional DMLs/operations as needed.

What after-save can do:

• All of before-save's actions
• Update related records (parent or child)
• Create new records of any type
• Callouts (if implemented as Apex action)
• Send emails (via Email Alert action)

The cost: each after-save runs in its own slot of the Save Order, contributes to governor limits, and slows down the original save.

When you get this error

Your before-save flow tried to do something only after-save supports. The Flow Builder usually rejects this at design time — you can't add an "Update Records" element on a different object inside a before-save trigger. But for actions that look available (custom Apex actions, for instance), you may not learn until runtime.

Fix: change the trigger phase

In Flow Builder, open the flow's start element. The Optimize the Flow for option:

Change it to Actions and Related Records if you need cross-record updates.

A subtler timing issue

A before-save flow that touches a roll-up summary field doesn't see the latest roll-up value because roll-ups recalculate after the save. If your flow needs the post-roll-up value, use after-save. Or use a workflow on the parent record that fires when the rollup changes.

When the flow runs but the change "doesn't take"

After-save flows can update related records. But if the related record has its own after-save flow that updates back, you can hit recursion or the trigger depth limit. The platform sometimes silently drops the third+ change. Add an idempotency guard.