Salesforce Before-Save vs. After-Save Record-Triggered Flows

A Salesforce before-save record-triggered flow is suited to updating fields on the record that triggered it. An after-save flow runs after the record is saved and can handle actions that require the saved record or affect related records. Choosing the timing by the work being done helps keep automation understandable and efficient.

Use before-save for same-record field updates

Before-save flows run as the record is being saved and are designed for fast field updates on that same record. They are a good fit when a value can be derived from fields already available on the triggering record and no separate related-record action is required.

Because the update happens in the save process, it can avoid an extra update step. Keep the logic focused: overlapping flows that write the same fields can make results dependent on execution order and harder to troubleshoot.

• Use clear entry conditions so unchanged records do not run unnecessary logic.
• Set derived fields consistently and document their source fields.
• Check interactions with validation rules and other automation.

Use after-save for actions that need a saved record

After-save flows are appropriate when the automation must create or update related records, launch downstream actions, or use the record after it has been committed. Examples include creating a follow-up task or updating a related object based on a completed change.

The additional capability brings more opportunities for recursion or duplicate actions. Define what happens on create, on update, and when a record re-enters the criteria. Where an action should happen only once, store or derive a reliable state rather than relying on a broad condition.

• Specify create and update behavior separately.
• Prevent repeated actions when unrelated fields change.
• Review flows, triggers, and workflow automation that touch the same records.

Test behavior, not only the flow canvas

Test representative records for each entry condition, including records that should not qualify. Confirm the field values, related records, and any actions after save. Include bulk updates where possible because automation that works for one record may behave differently at volume.

Before activation, review execution order, fault paths, permissions, and rollback expectations. A small sandbox test and a change log make it easier to spot loops or unintended writes before the flow affects live CRM data.