Autolaunched Flows and Subflows

Why This Topic Matters
The Advanced Process Automation section of the Salesforce Advanced Administrator exam tests your ability to choose the right automation tool and design it in a scalable, maintainable way. Autolaunched flows and subflows sit at the heart of that skill set. Autolaunched flows let you run complex logic without any user interaction, and subflows let you break large automations into reusable, modular pieces. Exam questions frequently describe a business scenario and ask you to identify which flow type to use, how to pass data between flows, or how to troubleshoot behavior such as faults, versioning, or governor limits. Understanding this topic also reflects real-world best practice: Salesforce recommends Flow as the primary declarative automation tool, and well-architected orgs rely heavily on autolaunched flows and subflows.

What Is an Autolaunched Flow?
An autolaunched flow is a flow that runs in the background with no user interface. It has no Screen elements and is not started by a user clicking through pages. Instead, something else invokes it. In Flow Builder, when you create a new flow you will see the type Autolaunched Flow (No Trigger). This distinguishes it from record-triggered flows, schedule-triggered flows, and platform event-triggered flows, which are also background flows but have a built-in trigger.

Key characteristics of an autolaunched flow:
- It contains no Screen elements and no Local Action elements.
- It can include logic elements (Decision, Assignment, Loop, Collection Sort, Collection Filter), data elements (Get, Create, Update, Delete Records), and Action elements (Send Email, Submit for Approval, Post to Chatter, invocable Apex, and so on).
- It can include a Pause element in many configurations, allowing the flow to wait for a time or a platform event.
- It runs in system context without sharing by default, meaning it ignores the running user's permissions, field-level security, and sharing rules. This is a critical exam point: an autolaunched flow can read and write records the invoking user could not normally access.
- It can accept input variables and return output variables, making it ideal for reusable logic.

How an Autolaunched Flow Is Invoked
Because it has no built-in trigger, an autolaunched flow must be started by something external. The exam expects you to know these invocation methods:
- Subflow element: Another flow calls it. This is the most common pattern and the basis of modular design.
- Apex: Developers can start it using the Flow.Interview class or by calling it as an invocable action.
- REST API: External systems can start it via the Custom Invocable Actions endpoint.
- Scheduled Paths in record-triggered flows: A record-triggered flow can call an autolaunched flow as a subflow, including from scheduled paths.
- Einstein Bots, Experience Cloud, and other platform features can invoke autolaunched flows as actions.
- Process Builder (now retired for new processes) historically launched autolaunched flows; exam questions may still reference migrating this pattern to Flow.

Note that autolaunched flows cannot be launched directly from a button, link, Lightning page component, or quick action, because those require a user interface. If a question describes a user clicking something to start logic, the correct flow type is a screen flow, not an autolaunched flow.

Input and Output Variables
Autolaunched flows communicate with the outside world through variables. When you create a variable in Flow Builder, you can check Available for input and/or Available for output.
- Available for input: The calling flow, Apex, or API can set this value when the flow starts. Typical examples include a record ID, a record variable, or a collection of records.
- Available for output: The value can be read by the caller after the flow finishes. Typical examples include a calculated amount, a status text, or a created record ID.
Only variables marked for input or output appear in the Subflow element mapping. If an exam question says a subflow's variable is not visible in the parent flow, the answer almost always involves these checkboxes.

What Is a Subflow?
A subflow is simply a flow that is called from another flow using the Subflow element. The calling flow is often called the parent flow. Subflows allow you to:
- Reuse the same logic across many flows (for example, a standard address validation routine or a discount calculation).
- Simplify large flows by splitting them into readable, testable pieces.
- Centralize changes: updating the subflow updates behavior everywhere it is used.
- Reduce maintenance errors and support a layered, enterprise-grade automation design.

Compatibility rules you must know for the exam:
- A screen flow can call screen flows or autolaunched flows as subflows.
- An autolaunched flow can only call autolaunched flows (it cannot call a flow containing screens because there is no UI to display them).
- A record-triggered flow can call autolaunched flows as subflows. Record-triggered flows cannot be called as subflows.
- Schedule-triggered and platform event-triggered flows can call autolaunched subflows.

How Subflows Work at Runtime
When the parent flow reaches a Subflow element, it passes input values, runs the referenced flow, waits for it to finish, receives output values, and then continues. Several behaviors are important:
- Versioning: In production, the Subflow element always runs the active version of the referenced flow. When debugging in Flow Builder, you can choose to run the latest version instead, but end users only ever experience the active version. If a subflow has no active version, the parent flow fails at runtime.
- Transactions and limits: A subflow runs in the same transaction as its parent. Governor limits (SOQL queries, DML statements, CPU time) are shared across the parent and all subflows. Splitting logic into subflows does not give you extra limits.
- Fault handling: If a subflow hits an unhandled error, the fault bubbles up to the parent. You can connect a Fault path from the Subflow element in the parent to handle it gracefully, or build fault paths inside the subflow itself.
- Data passing: Record variables and collection variables can be passed in and out, enabling bulk-friendly designs. Always pass collections rather than calling a subflow inside a Loop with a Get Records element, which risks hitting SOQL limits.
- Running context: A subflow generally inherits the context of the parent flow. A screen flow running in user context that calls a subflow set to system context will run that subflow in system context, so be alert to security implications.

Designing Good Autolaunched Flows and Subflows
Best practices that often appear as correct answers:
- Use descriptive names and descriptions so parent flows are easy to read.
- Keep subflows focused on a single responsibility.
- Avoid DML and queries inside loops; collect records and perform a single Create or Update after the loop.
- Add Fault paths to data elements and Subflow elements, and log or email errors.
- Use the Debug feature with input values to test autolaunched flows before activation.
- Consider the One Record-Triggered Flow per Object per Trigger pattern, delegating detailed logic to autolaunched subflows.
- Remember permissions: users need the Run Flows permission (or Flow User checkbox) to run flows, and administrators need Manage Flow to build them. System-context flows still require the user to be able to run the flow itself.

Common Exam Scenarios
1. A company needs the same complex pricing calculation used in three different flows. The answer: build an autolaunched flow with input and output variables and call it as a subflow.
2. An administrator updated a subflow but the parent flow still shows old behavior. The answer: the new version of the subflow was not activated; the parent runs the active version.
3. Users without access to a related object need a flow to update records on that object. The answer: an autolaunched flow running in system context without sharing.
4. A developer needs to start business logic from Apex and get a result back. The answer: an autolaunched flow with output variables, invoked from Apex.
5. A flow should be started when a user clicks a button. The answer is a screen flow, not an autolaunched flow, even if the screen flow immediately calls an autolaunched subflow.
6. A record-triggered flow is hitting SOQL limits because it calls a subflow inside a loop. The answer: restructure to pass a collection into the subflow and move queries outside the loop.

Exam Tips: Answering Questions on Autolaunched Flows and Subflows
- Identify the trigger first. If a scenario mentions a user interface (button, page, quick action), the primary flow must be a screen flow. If the logic runs in the background and is called by another flow, Apex, or an API, it is an autolaunched flow. If a record change starts it, it is record-triggered, not autolaunched.
- Look for the word reuse. Whenever a question emphasizes using the same logic in multiple places or reducing duplication, the answer involves a subflow.
- Check the variable checkboxes. Problems passing data between flows almost always point to Available for input or Available for output not being selected, or to a data type mismatch.
- Remember the active version rule. Subflows run the active version in production. Debug mode may run the latest version, which explains discrepancies between testing and real behavior.
- Know the context defaults. Autolaunched flows run in system context without sharing by default; this is a security consideration, not just a technical detail.
- Limits are shared. Eliminate any answer suggesting subflows provide separate governor limits or separate transactions.
- Compatibility matters. Autolaunched flows cannot contain or call screens. Record-triggered flows cannot be subflows but can call autolaunched subflows.
- Prefer declarative, bulk-safe, fault-tolerant designs. When multiple answers seem viable, choose the one that avoids Apex when Flow can do the job, avoids DML in loops, and includes error handling.
- Eliminate retired tools. Answers recommending new Workflow Rules or Process Builder processes are generally incorrect in current exam versions; Flow is the recommended tool.
- Read for keywords like system context, without sharing, Apex, API, input variable, output variable, active version, and Fault path. These signal exactly which concept the question is testing.

Mastering autolaunched flows and subflows means you can design automation that is modular, secure, and scalable, and you will be able to confidently eliminate distractors on the exam by matching each scenario to the correct flow type, invocation method, and data-passing technique.