How a Record-Triggered Flow Starts
When you need to automate logic based on data changes, a Record-Triggered Flow is usually the first tool I reach for. It’s the modern way to handle what we used to do with Apex triggers or Process Builder. Basically, you’re telling Salesforce to watch a specific object and run some logic whenever a record is created, updated, or deleted. But the trick isn’t just making it run – it’s making it run at the right time without breaking your org’s performance.
I’ve seen plenty of admins get frustrated because their automation didn’t fire when they expected. Usually, it comes down to how the entry conditions are set up. If those criteria aren’t met, the flow won’t even wake up. It’s a “gatekeeper” mechanism that keeps your system from wasting resources on records that don’t need processing.
The Four Main Trigger Events
You have to pick exactly what event kicks things off. Here is the breakdown of your options:
- A record is created: This is for your “Welcome” emails or setting default values that can’t be handled by standard field defaults.
- A record is updated: This fires every time someone hits save on an existing record, provided your entry conditions match.
- A record is created or updated: This is the workhorse. I use this for most business logic to ensure the rules apply regardless of how the record got there.
- A record is deleted: This only works for after-save logic. It’s great for cleaning up related data before the parent record vanishes.
Optimizing Your Record-Triggered Flow Performance
One thing that trips people up is the choice between “Fast Field Updates” and “Actions and Related Records.” In the dev world, we call these before-save and after-save triggers. If you’re just changing a field on the record that triggered the flow, always use Fast Field Updates. It is significantly faster. Why? Because it happens before the data is even committed to the database, saving Salesforce the trouble of a second “save” operation.
But if you need to update a parent Account when a Contact changes, or if you need the ID of a brand-new record, you’ll need the after-save option. Just keep in mind that after-save flows are heavier. If you’re struggling to decide, I wrote a piece on Apex vs Flow that goes deeper into when to stick with declarative tools and when to move to code.
Setting Smart Entry Conditions
Look, the “Every time a record is updated and meets the condition requirements” setting is a trap if you aren’t careful. If you leave it on the default, the flow runs every single time a user hits save, even if the fields you care about didn’t change. This is how you end up with CPU timeout errors.
Always try to use the “Only when a record is updated to meet the condition requirements” option. This ensures the flow only fires at the exact moment the record changes from “not matching” to “matching.” It’s the best way to prevent your automation from running in circles.
Pro Tip: If you’re dealing with high volumes of data, pay close attention to recursion. If an after-save flow updates the same record that triggered it, you might accidentally start the whole cycle over again. Use clear entry criteria to avoid these infinite loops.
Common Real-World Configuration
Let’s look at a standard setup I use for Opportunity management. Say you want to notify a team when a deal closes. Here is how that looks in the configuration panel:
| Setting | Value |
|---|---|
| Object | Opportunity |
| Trigger Event | A record is updated |
| Condition Requirements | StageName Equals ‘Closed Won’ |
| When to Run | Only when a record is updated to meet the requirements |
| Optimization | Actions and Related Records (After-Save) |
In this scenario, we use after-save because we might need to create a “Contract” record or send an email. If we were just updating a custom “Closing Date” field on the Opportunity itself, we would switch to Fast Field Updates to keep the org snappy.
Also, don’t forget about Salesforce Flow bulkification. Even if you think you’re only editing one record at a time, tools like Data Loader or bulk API integrations will push records through in batches. If your flow isn’t built to handle collections, it’s going to fail when you least expect it.
Key Takeaways
- Before-Save is for speed: Use Fast Field Updates for any change happening on the triggering record itself.
- After-Save is for reach: Use Actions and Related Records when you need to talk to other objects or send emails.
- Entry criteria are vital: Use the “Only when updated to meet conditions” checkbox to save on processing power and avoid recursion.
- Bulkify everything: Never put a Get Records or Update Records element inside a loop. Salesforce will stop you eventually.
- Debug often: Use the “View as another user” feature in the debugger to make sure your permissions are actually working.
Getting a Record-Triggered Flow to run is easy, but getting it to run efficiently is where the real skill comes in. Start small, test with the debugger, and always keep an eye on your entry conditions. If you follow these patterns, your automations will be much easier to maintain as your org grows.