Autolaunched Flow
An Autolaunched Flow is a Salesforce Flow that runs without showing any screens to a user.
Definition
An Autolaunched Flow is a Salesforce Flow that runs without showing any screens to a user. It executes in the background and is started by something other than a person clicking through a wizard. That starter can be a record save, a scheduled time, a published platform event, an Apex class, a process, another flow called as a subflow, a custom button or link, an Agentforce action, or an external system through the Flow REST API.
The key difference from a Screen Flow is that an Autolaunched Flow has no user interface. Decisions, loops, data lookups, record creates and updates, and Apex callouts all work the same way in Flow Builder. What changes is who sees the result, which is nobody. The flow runs, finishes, and hands control back to whatever called it. That makes it the standard pattern for background automation, integrations, and any work that fires from an event rather than a click. Salesforce now recommends flows for most automation that older tools like Workflow Rules and Process Builder used to handle.
How Autolaunched Flows fit the Salesforce automation model
Pure autolaunched versus triggered variants
The phrase Autolaunched Flow is used two ways, and the difference matters. In the strict sense, a pure Autolaunched Flow has no trigger defined inside it. Salesforce describes it as a flow that runs when something else initiates it, which gives you control over exactly when it runs. You point a custom button, an Apex class, a subflow element, a Visualforce page, or the REST API at it, and it fires on demand. Cloning data from a closed case when an agent decides to do so is a classic example, because the timing needs human judgment but the work needs no screen. In the broader sense that admins use day to day, the autolaunched family also includes the triggered types you pick when you create a flow: Record-Triggered, Schedule-Triggered, and Platform Event-Triggered. All of them run with no screens, which is why people group them together. The distinction is simple. A pure autolaunched flow waits to be called. A triggered flow listens for its own event and fires itself. Knowing which one you have tells you how it gets invoked and where to look when you debug it.
Record-Triggered Flows and the legacy tools they replace
Record-Triggered Flows are the most common autolaunched type. They fire when a record is created, updated, or deleted, and they cover the work that Workflow Rules and Process Builder used to do. Workflow Rules and Process Builder are both retired for new automation, so a Record-Triggered Flow is the supported choice today. One flow engine handles field updates, email alerts, related record creation, complex conditions, loops, and callouts. These flows run in one of two contexts. A Before-Save flow runs as the record is being saved, before the data is committed. It can change fields on the same record with no extra database operation, which makes it fast and the right replacement for a Workflow Rule field update. An After-Save flow runs once the record is committed. It can query and change related records, send emails, and call other automation, at the cost of being slower than before-save. When several flows run on the same object, you set a trigger order value from 1 to 2,000 to control sequence. An after-save flow cannot run before a before-save flow or before an Apex trigger, even with a lower order value.
Scheduled and Platform Event triggers
A Schedule-Triggered Flow runs on a clock instead of a record change. You set a start date, a time, and a frequency such as daily or weekly. You can also add a query so the flow runs once for each record that matches a filter. This covers work that Scheduled Apex used to own, like sending renewal reminders, flagging stale opportunities, or running nightly cleanup. The flow does the same job without writing a schedulable Apex class. A Platform Event-Triggered Flow runs when a platform event message publishes. Platform events are the message bus Salesforce uses for event-driven work, both inside the org and with outside systems. When a payment processor publishes an event saying a charge succeeded, a subscribed flow can fire once per message and update the related record. These flows run asynchronously, separate from the transaction that published the event, so they get their own set of governor limits. That isolation is useful, because heavy work triggered by an event does not slow down the original save.
Calling Apex, and being called from Apex
Autolaunched Flows and Apex call each other, which lets admins and developers split the work. A flow calls Apex through an invocable method, a public method marked with the InvocableMethod annotation so it shows up as an action on the canvas. Use this when a step needs logic that flow elements cannot express cleanly, such as a complex calculation or a specialized callout. The flow stays readable while the hard part lives in code. Going the other direction, Apex starts an autolaunched flow with the Flow.Interview.start method. You pass the flow name and a map of input variables, and the flow runs to completion inside your transaction. This is handy when a trigger or controller needs to run admin-owned logic without duplicating it in code. Because both directions share the same transaction and the same limits, the team has to agree on where each piece of logic lives. A common pattern is a thin flow for orchestration and branching, with Apex handling the parts that need real code. That split keeps each tool doing what it is best at.
Governor limits and bulkification
An Autolaunched Flow runs inside a Salesforce transaction, so it shares that transaction governor limits for queries, DML statements, and CPU time. This catches teams off guard most often with Record-Triggered Flows. When a data load or a mass update touches 200 records at once, the flow processes the whole batch in a single transaction, not one record at a time. The flow has to be built to handle the batch, the same way Apex has to be bulkified. The usual mistake is putting a Get Records or an Update element inside a loop. Each pass adds another database operation, and a large batch blows the limit fast. The fix is to loop over records to build a collection in memory, then run a single Update or Create on that collection once the loop ends. Flow Builder nudges you toward this with collection variables and the option to update records using a collection. The tooling helps, but the discipline is on you. A flow that looks fine on one test record can still fail in production when real volume arrives.
Debugging, fault paths, and monitoring
Flow Builder includes a Debug button that runs the flow with sample inputs and shows each element as it executes, along with variable values at every step. This is the fastest way to see why a branch was taken or where a value came from before you ever touch production. For triggered flows, you can debug against a real record to see the actual behavior on save. In production, the biggest risk is a silent failure. By default, when a flow element like a Create Records hits an error, the flow stops and the running user may see a generic message, or with triggered flows the whole transaction can roll back. Add a fault path to every element that touches data or calls Apex, route it to error handling, and log what happened. That turns an invisible failure into something you can find. Salesforce also sends flow error emails to the admins you configure, and failed background flows can be paused and resumed from Setup. Mature teams build reports on flow run history to watch fail rates and timing, so a regression shows up on a dashboard instead of in a support ticket.
How to build an Autolaunched Flow
You build an Autolaunched Flow in Flow Builder. The steps below create a pure autolaunched flow that you can call from a button, Apex, a subflow, or the REST API. For a triggered variant, you pick Record-Triggered, Schedule-Triggered, or Platform Event-Triggered at the start instead, then configure the trigger.
- Open Flow Builder and pick the type
From Setup, go to Flows and click New Flow. Choose Autolaunched Flow (No Trigger) for a flow you will call yourself, or choose a triggered type if you want it to fire on a record, schedule, or event.
- Define input and output variables
In the Manager, create resource variables and mark them Available for input or output as needed. These are how a button, Apex, or a parent flow passes data in and reads results back out.
- Build the logic on the canvas
Add Get Records, Decision, Loop, Assignment, and Create or Update Records elements to do the work. Keep DML out of loops by collecting records into a variable and committing once after the loop.
- Add fault handling
On every data and Apex element, drag a fault connector to a handler that logs the error or sends a notification. Silent failures are the hardest flow bugs to find later.
- Debug, save, and activate
Use the Debug button to run the flow with sample inputs and confirm each step. Save with a clear name and description, then click Activate so callers can run it.
Autolaunched Flow (No Trigger) for an on-demand flow, or a triggered type to fire automatically. This choice is set when you create the flow.
A readable label and a unique API name. Apex and the REST API reference the flow by its API name, so pick it carefully.
How the flow runs, in system context or in the running user context. This decides whether sharing and field permissions are enforced.
- A flow does nothing until you activate it. A saved but inactive flow will not run when called.
- Record-Triggered Flows run on the whole batch in one transaction, so build for bulk, not for a single test record.
- An after-save flow cannot run before a before-save flow or an Apex trigger, regardless of the trigger order value you set.
- Run context controls security. Running in system context skips the user sharing and field-level security, so confirm that is what you want.
Trust & references
Cross-checked against the following references.
- Flow TypesSalesforce
- Decide Between Before-Save and After-Save Record-Triggered FlowsSalesforce
Straight from the source - Salesforce's reference material on Autolaunched Flow.
- Triggers for Autolaunched FlowsSalesforce
- Before-Save Record-Triggered FlowsSalesforce
Hands-on resources to go deeper on Autolaunched Flow.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What distinguishes an Autolaunched Flow from a Screen Flow?
Q2. Which of these can trigger an Autolaunched Flow?
Q3. What are Autolaunched Flows the modern replacement for?
Discussion
Loading discussion…