#5🔄 FlowsRookie

Using After-Save When Before-Save Would Do

“Built an after-save flow to update the triggering record. Wasted a DML operation on every single save.”

What Happened

I needed to auto-populate a field on Opportunity when it was created. Built an after-save record-triggered flow that did an Update Records on the same record. It worked, but I was burning an extra DML operation on every single Opportunity create. Multiply that across the org and I was eating governor limits for breakfast. A before-save flow does the same thing with zero DML because it modifies the record in memory before it's committed.

The Wrong Way

// After-Save Record-Triggered Flow on Opportunity
// Entry: ISNEW()
// Action: Update Records → Current Record
//   Set Region__c = "Southeast" (based on logic)
//
// This works but costs 1 DML operation per record.
// In a bulk operation of 200 records, that's 200
// unnecessary DML operations.

The Right Way

// Before-Save Record-Triggered Flow on Opportunity
// Entry: ISNEW()
// Action: Assignment Element (NOT Update Records)
//   {!$Record.Region__c} = "Southeast"
//
// The record hasn't been saved yet, so you're
// modifying it in memory. Zero DML cost.
// Zero extra SOQL. Blazing fast.
//
// Rule: If you're only updating the triggering
// record, ALWAYS use Before-Save.

The Lesson

Before-save flows are free. After-save flows cost DML. If you're only changing the triggering record, before-save is always the answer.

Share this mistake on X

Don't make this mistake.

Hire someone who already did.

View Consulting →

#4 Hardcoded Record IDs in Flows: The Sandbox Surprise SOQL Query Inside a For Loop (The Classic) #6

Enjoyed this? Get more like it.

Glen's Musings — AI, investing, and building things. Occasional. Free.