A few months before Salesforce officially retired Process Builder, we were in the middle of an automation audit for a mid-size distribution client. Their org had grown organically over five years — dozens of Process Builders daisy-chaining into each other, a handful of Workflow Rules still firing time-based email alerts, and a growing number of Record-Triggered Flows that a previous consultant had built without fully understanding the before-save versus after-save distinction. One Flow in particular was stamping a timestamp field on Opportunities — a simple operation — but it was running after-save, burning a DML operation on every single record update, and occasionally tripping the org's governor limits during end-of-quarter bulk loads. The fix was a two-minute change: move the logic to before-save. The lesson stuck.
Now that Workflow Rules and Process Builder are both retired, Flow Builder is the only declarative automation platform available to admins. That consolidation is genuinely a good thing — one tool, one mental model — but it comes with a responsibility that the old tools papered over: you have to choose the right Flow type from the start, because the five types behave very differently and the wrong choice creates problems that only show up under load or in edge cases.
Here is how we think about each type and when we reach for it.
Record-Triggered Flow: the workhorse
Record-Triggered Flows fire whenever a record is created, updated, or deleted and it meets the criteria you configure. This is the direct replacement for Process Builder and most Workflow Rules, and it is by far the type we use most often on implementation projects.
The decision that trips up admins most frequently is not whether to use this type — that is usually obvious — but when inside the transaction to run the logic. Salesforce gives you two options: before the record is saved to the database, or after.
Before-save execution runs while Salesforce still has the record in memory, before it writes anything to disk. Because you are operating on the in-memory record, you can update fields on that same record at zero DML cost — the update travels to the database as part of the same write that was already happening. The tradeoff is that before-save Flows are limited: you cannot create or update related records, because those related records need a committed ID to reference, and nothing is committed yet. We use before-save for exactly the scenario in that distribution client's org — stamping a calculated field, defaulting a value based on other field inputs, setting a status based on criteria that are knowable at save time. It is faster and does not touch DML limits, and for straightforward field-setting logic there is no reason to run it after-save.
After-save execution runs once the record is committed and has a stable record ID. Now you can go across relationships — create child records, update parent or sibling records, send notifications, kick off external callouts. The cost is that this counts against your DML governor limits, which matters in orgs processing bulk operations. On a project for a logistics company running nightly batch imports of several thousand records at once, we had to be very deliberate about which Record-Triggered Flows were running after-save and what DML each one was performing. The rule we follow internally: if the logic only touches fields on the triggering record itself, before-save; if it needs to touch anything else, after-save.
Screen Flow: guided user experiences
Screen Flows are the type you reach for when a human is sitting in front of Salesforce and needs to be walked through a multi-step process. They render UI elements — input fields, dropdowns, data tables, display text — and they do not proceed until the user interacts and clicks Next.
We have used Screen Flows to replace clunky multi-tab data entry processes for service teams, to build case resolution wizards that ensure agents capture the right information before closing a case, and to power list-view actions that let a manager update a batch of records after confirming a summary screen. In one project with a Vietnamese insurance brokerage, the sales team had a 12-field qualification form they were filling out across three different record pages; we collapsed it into a single Screen Flow launched from a button, collected all the data in one guided session, and created the related records at the end. The adoption improvement was immediate.
Screen Flows respect the running user's permissions the same way any Lightning page does — FLS applies, and if a user cannot see a field, the screen element will render empty. When you embed a Screen Flow in a Lightning Record Page using the Flow component, you can pass the page's record ID in as an input variable, which means the Flow can pre-populate fields or make decisions based on the record it was launched from.
Scheduled Flow: batch automation on a clock
Scheduled Flows run on a configured schedule — hourly, daily, weekly — and at the moment they execute, they query for all records that match a defined filter and process them as a batch. This is the replacement for time-based Workflow actions and a reasonable substitute for many Apex batch jobs that only needed declarative-level logic.
The behavioral detail that matters most here: the filter is evaluated at run time, not when records were created. If you build a Scheduled Flow to send a reminder notification for Opportunities whose close date is within seven days, it will evaluate which Opportunities meet that criterion at the exact moment the Flow fires each morning — not when those Opportunities entered the pipeline. This is the correct behavior, but it catches admins off guard when they expect a Scheduled Flow to "remember" which records were flagged at record creation time. If you need that kind of record-level timing logic, you are looking at a different design, likely combining a Record-Triggered Flow to stamp a field with the After-Save approach and a Scheduled Flow reading that field.
We use Scheduled Flows for weekly data quality sweeps, daily SLA deadline alerts, and periodic field updates that should run against a whole segment of records rather than reacting to individual changes. One thing Scheduled Flows cannot do: they cannot be launched by a user and cannot be embedded in a page. They run on schedule, period.
Autolaunched Flow: the reusable building block
Autolaunched Flows have no trigger of their own and no UI. They exist to be called by something else — another Flow, an Apex class, a REST API request — and they accept input variables, perform logic, and return output variables. Think of them as the declarative equivalent of a utility method: encapsulated, testable, and reusable across multiple callers.
We use Autolaunched Flows heavily in complex orgs where the same logic needs to run from multiple places. Rather than duplicating twenty elements across three different Record-Triggered Flows, we extract that logic into an Autolaunched Flow and call it as a subflow from each one. When the business rule changes, we update one place. On projects where Apex is handling the orchestration but a section of the logic is straightforward enough to manage declaratively, we have Apex invoke the Autolaunched Flow via the Flow.Interview API, keeping the declarative logic admin-maintainable without redeploying code.
Subflow composition — breaking large Flows into smaller Autolaunched units and calling them from a parent Flow — is one of the patterns we push hard on every project. It makes individual units testable, keeps each Flow's canvas manageable, and means that when an admin needs to update a piece of logic, they can find the right subflow without reverse-engineering a 200-element canvas.
Platform Event-Triggered Flow: for event-driven integration
Platform Event-Triggered Flows subscribe to a specific Platform Event and fire whenever that event is published, whether from within Salesforce or from an external system. This type is less common in purely internal org automation, but it becomes essential in orgs using Salesforce as part of an event-driven integration architecture.
The scenario we see most often: an external order management system publishes a Platform Event to Salesforce when an order status changes — say, when fulfilment is confirmed. A Platform Event-Triggered Flow picks up that event, reads the payload, and updates the corresponding records in Salesforce without requiring the external system to make a direct API call to update records itself. The event is the handshake; the Flow handles the Salesforce side of the response. For admins working in orgs with active integration teams, understanding this type is what separates someone who can participate in integration design conversations from someone who cannot.
How we approach this on every project
When Salesforce retired Workflow Rules and Process Builder, we ran migration assessments for several clients and the pattern we saw repeatedly was that people had been using Process Builder as a one-size-fits-all tool — triggering off record changes, running sequential conditions, firing off actions — without any formal framework for which tool belonged where. Flow's five-type model forces that thinking upfront, and that is genuinely a better place to be.
The shorthand we use internally: if a record changed and logic needs to respond, start with Record-Triggered and immediately decide before-save or after-save based on whether you are touching only the triggering record or reaching across relationships. If a user needs to interact, it is a Screen Flow. If timing and batching matter more than a specific record event, it is a Scheduled Flow. If you need reusable logic with no trigger of its own, it is Autolaunched. If you are consuming events from an integration layer, it is Platform Event-Triggered. Getting that decision right at the start of design is not a small thing — it determines performance, governor limit exposure, and how maintainable the automation is six months later when the person who built it has moved on.
