Salesforce Flow Interview Questions and Answers (2026)

These are the Salesforce Flow interview questions I'd actually ask, with the answers I'd want to hear. They cover record-triggered flows (before-save and after-save), the order of execution, Flow Trigger Explorer, scheduled paths, fault handling, bulkification, invocable Apex, screen flows with LWC, HTTP callouts, Platform Event-triggered flows, and the Flow vs Apex decision.

Don't memorise the wording. Read each answer, close the page, and explain it out loud in your own words. Interviewers aren't checking whether you remember Flow Builder labels. They want to know whether you understand why each option exists and what it costs at run time.

Fundamentals

What types of flows can you build, and when would you use each one?

There are five that come up in practice:

• Screen flows guide a user through screens. Use them for wizards, guided data entry and quick actions.
• Record-triggered flows run when a record is created, updated or deleted. They replace most Workflow Rules, Process Builder processes and many simple triggers.
• Schedule-triggered flows run on a schedule against a set of records, for example a nightly clean-up.
• Platform Event-triggered flows run when a platform event message is received.
• Autolaunched flows (no trigger) are started by something else: Apex, a REST call, another flow as a subflow, or a button.

A good answer picks the type from the trigger (who or what starts it), then explains the constraints that come with it.

What's the difference between a before-save and an after-save record-triggered flow?

In Flow Builder these are labelled Fast Field Updates (before-save) and Actions and Related Records (after-save).

A before-save flow runs before the record is written to the database. It can only change fields on the triggering record ($Record). It can't create or update other records, send emails, call Apex actions or run subflows. In return it's very cheap, because the field changes ride along with the save that's already happening.

An after-save flow runs once the record has been saved, so the record has an Id and system fields are populated. It can create and update related records, call actions and subflows, and add scheduled or asynchronous paths.

Rule of thumb: same-record field updates belong in before-save. Everything else belongs in after-save.

What the interviewer is really checking: whether you pick before-save by default for same-record updates, not after-save out of habit.

Why is updating the triggering record in an after-save flow a bad idea?

Because by then the record has already been saved. Your Update Records element is a second DML operation on the same record, and that second save runs the save procedure again: before triggers, validation rules, duplicate rules, after triggers and other automation all run a second time.

That costs DML statements, CPU time and SOQL queries from the shared transaction budget, and it's how accidental recursion starts. The same field change in a before-save flow costs no extra DML at all.

There are legitimate exceptions, for example a value that depends on related records created in the same after-save flow. But you should be able to explain the cost when you choose it.

What do entry conditions do, and what does "only when a record is updated to meet the condition requirements" mean?

Entry conditions decide whether the flow runs for a record at all. Filtering here is cheaper and clearer than starting the flow and exiting at a Decision element.

For update triggers you choose between two options:

• Every time a record is updated and meets the condition requirements. The flow runs on every save while the conditions are true, even if nothing relevant changed.
• Only when a record is updated to meet the condition requirements. The flow runs only when the record goes from not meeting the conditions to meeting them. This is the edge-triggered behaviour most people actually want, such as "when Stage changes to Closed Won".

Picking the first option for a status-change requirement is a classic bug. The automation fires again every time someone edits an unrelated field on a Closed Won opportunity.

What are $Record and $Record__Prior?

$Record is the triggering record with its current values. In a before-save flow you assign new values to $Record fields directly. In an after-save flow it's the saved state.

$Record__Prior holds the field values from before the update. It's available in flows that run on update, and it's empty on create. You use it to detect real changes. For example, a Decision that checks $Record.StageName not equal to $Record__Prior.StageName tells you whether this save actually moved the stage.

It's the Flow equivalent of comparing Trigger.new with Trigger.oldMap in Apex. Interviewers often ask for that comparison to see whether you can move between the two tools.

Does a flow run in user context or system context?

It depends on the flow type and its settings. Record-triggered flows run in system context, so they can read and update records regardless of the running user's permissions. Screen flows run in user context by default, so the user's object permissions, field-level security and sharing apply. Autolaunched flows have a setting in the flow's advanced properties that lets you choose.

This matters for security reviews. A screen flow that you switch to system context without sharing can show a user records they couldn't otherwise see. Only do that deliberately, and keep the screens restricted to the data the user needs.

What the interviewer is really checking: whether you think about data exposure, not just whether the flow "works" when you test it as an admin.

Intermediate

Where do record-triggered flows run in the order of execution compared with Apex triggers?

Before-save flows run before Apex before triggers. After-save flows run after Apex after triggers, later in the save procedure: after assignment, auto-response, workflow and escalation rules, but before roll-up summary fields are recalculated and the transaction commits.

Two practical consequences:

1. If a before-save flow and a before trigger both set the same field, the trigger runs second, so the trigger's value wins.
2. An after-save flow can see changes made by after triggers, but anything it updates re-enters the save procedure for those records.

Everything in one save, flows and Apex together, shares one set of governor limits.

You have several record-triggered flows on Opportunity. How do you control the order they run in?

Open Flow Trigger Explorer for the object and trigger type. It lists every record-triggered flow that fires for, say, Opportunity on create or update, grouped by when they run. That's the first place I look when someone says "something keeps changing this field".

To set the order, give each flow a Trigger Order value in its advanced settings. Flows with lower values run first. If you leave it blank or two flows share a value, you're relying on a default ordering, and nobody should depend on that.

The design discussion that follows is usually about how many flows per object you want. Some teams keep one before-save and one after-save flow per object. Others prefer smaller flows with tight entry conditions and an explicit trigger order. Either works if it's consistent and documented.

What is a scheduled path, and what are its constraints?

A scheduled path runs part of an after-save record-triggered flow later, relative to a time source. That can be when the record was created or updated, or a date/time field on the record such as CloseDate or a custom renewal date. "Seven days before the renewal date, create a task for the owner" is the textbook example.

The constraints to mention:

• Scheduled paths only exist in after-save flows.
• For update triggers, the flow has to run only when a record is updated to meet the condition requirements. Otherwise every edit would queue another scheduled action.
• They run in a separate transaction later, so the record may have changed by then. Re-check the data with a Get Records or a Decision before acting.

When would you use the "Run Asynchronously" path?

Use it when an after-save flow needs to do something that can't or shouldn't happen inside the user's save transaction. The main example is an HTTP callout or an external action. Callouts aren't allowed while the transaction has uncommitted work, and the synchronous part of a record-triggered flow always has uncommitted work.

The asynchronous path runs after the original transaction commits, in its own transaction with its own limits. The trade-offs are the usual async ones. The user doesn't wait, but they also don't see an error if it fails. So pair it with a fault path that logs the failure somewhere an admin will see it.

What happens when a flow element fails, and how do you handle it?

Without a fault path, an unhandled fault stops the flow. In a record-triggered flow that error rolls back the whole save, so the user sees a generic flow error and the admin receives a fault email.

Elements that can fail (Get, Create, Update and Delete Records, actions, Apex, callouts) can have a fault connector. On that path, $Flow.FaultMessage holds the error text. Typical fault-path work:

• Log the error to a custom object or send it to the support team.
• In a screen flow, show a screen that tells the user what went wrong in plain language.
• In a record-triggered flow, use the Custom Error element to block the save with a clear message, much like a validation rule.

In screen flows there is also a Roll Back Records element for undoing earlier changes in the same transaction when a later step fails.

What the interviewer is really checking: whether you design for failure, or only for the happy path.

How do flows behave when Data Loader inserts 200 records at once?

Record-triggered flows are bulkified by the platform. Salesforce creates one flow interview per record, runs them together, and combines data elements across interviews where it can. If all 200 interviews reach the same Get Records or Update Records element, the platform can turn that into one query or one DML statement instead of 200.

That protection has limits. It works across interviews at the same element. It doesn't fix a Get Records or Update Records element you put inside a Loop, because each iteration is its own query or DML within each interview. And all 200 interviews share the transaction's governor limits with every trigger and other flow on the object.

So "flows are bulkified" is true for straight-line flows and false for badly built ones.

What's wrong with putting Get Records or Update Records inside a Loop?

Every loop iteration runs its own SOQL query or DML statement. A synchronous transaction allows 100 SOQL queries and 150 DML statements in total, shared with every trigger and flow in the save. A loop over 150 related contacts with an Update Records inside it fails even when only one parent record was saved.

The fix is the same pattern you use in Apex:

1. Query everything you need once, before the loop.
2. Inside the loop, use Assignment to change values on the loop variable and add it to a collection variable.
3. After the loop, run one Update Records on the collection.

Newer elements such as Collection Filter and Transform often remove the need for a manual loop altogether.

What the interviewer is really checking: whether you apply bulkification thinking to declarative tools, not just to Apex.

How do subflows work, and why would you use them?

A subflow is an autolaunched flow called from another flow with the Subflow element. You pass data in through variables marked Available for input and read results back from variables marked Available for output.

Use subflows to reuse logic, such as "create a case with our standard defaults" or "calculate the discount tier", across several screen and record-triggered flows. That way it's built, tested and fixed in one place. Record-triggered flows can call subflows from after-save paths, not from before-save.

Two cautions. A subflow runs in the same transaction as its parent, so its queries and DML count against the same limits. And changing a subflow's input or output variables can break every flow that calls it, so treat it like a public API.

Scenario-based

When an Opportunity is closed won, the business wants a renewal opportunity created and the account owner emailed. How would you build it?

I'd use one after-save record-triggered flow on Opportunity, because it creates a related record and sends an email, and before-save can do neither.

• Trigger: created or updated.
• Entry conditions: StageName equals Closed Won, run only when a record is updated to meet the condition requirements. That way, later edits to a closed opportunity don't create a second renewal.
• Create Records: the renewal opportunity, with values from $Record and a close date offset from the original.
• Send Email action to the account owner. If the email isn't urgent, put it on an asynchronous path so a mail failure can't roll back the renewal.
• Fault paths on both elements, logging to an error object.

Then I'd test it with a bulk update of 200 opportunities, not just one record in the UI.

A user reports "An unhandled fault has occurred in this flow". How do you debug it?

1. Read the fault email or the failed flow interview details. They name the element that failed and the underlying error, such as a validation rule, a required field or a limit exception.
2. Reproduce it with Debug in Flow Builder, using the same record and, if needed, running as that user. Permissions are a common cause in user-context flows.
3. Check what else ran. Use Flow Trigger Explorer and a debug log to see the triggers, flows and validation rules in the same transaction. The failing element is often just where a shared limit ran out.
4. Fix the cause, then add a fault path so the next failure gives the user a useful message and the admin a log entry.

What the interviewer is really checking: whether you have a method, not just "I'd look at the flow".

When an Account is created, you need to send it to an external REST API. How do you do that from a flow?

Two options:

1. HTTP Callout action. You set up a Named Credential (with an External Credential for the authentication), then add an HTTP Callout action in Flow Builder. It lets you describe the request and generate the response data structure from a sample payload. No Apex needed.
2. Invocable Apex. Write an @InvocableMethod with callout=true when you need custom authentication handling, payload shaping or error logic that would be painful to build in Flow.

Either way, in a record-triggered flow the callout must happen on the Run Asynchronously path or a scheduled path, not the synchronous after-save path. The record is created, the transaction commits, and then the callout runs. Add a fault path, because the external system will be down at some point.

How do you call Apex from a flow? Write an invocable method.

Annotate a public or global static method with @InvocableMethod. A class can have only one. The method takes a single List parameter and returns a List (or nothing). The flow runtime batches calls: if 200 interviews reach the action together, your method runs once with 200 inputs. So it must be bulkified, and the output list must line up with the input list.

public with sharing class AccountRiskScorer {
    @InvocableMethod(label='Score Account Risk' description='Returns a 0-100 risk score per Account')
    public static List<Integer> score(List<Id> accountIds) {
        Map<Id, Integer> openCases = new Map<Id, Integer>();
        for (AggregateResult row : [
            SELECT AccountId accId, COUNT(Id) total
            FROM Case
            WHERE AccountId IN :accountIds AND IsClosed = false
            WITH USER_MODE
            GROUP BY AccountId
        ]) {
            openCases.put((Id) row.get('accId'), (Integer) row.get('total'));
        }

        List<Integer> scores = new List<Integer>();
        for (Id accountId : accountIds) {
            Integer count = openCases.containsKey(accountId) ? openCases.get(accountId) : 0;
            scores.add(Math.min(count * 10, 100));
        }
        return scores;
    }
}

One query for every interview, with results returned in input order. For several inputs or outputs, use a wrapper class with @InvocableVariable fields.

How do you build a custom LWC for a screen flow and pass a value back to the flow?

Add the lightning__FlowScreen target in the component's js-meta.xml and declare the @api properties the flow can set or read. To send a value back, dispatch a FlowAttributeChangeEvent. For validation when the user clicks Next, expose an @api validate() method.

import { LightningElement, api } from 'lwc';
import { FlowAttributeChangeEvent } from 'lightning/flowSupport';

export default class SeatPicker extends LightningElement {
    @api maxSeats;
    @api selectedSeats;

    get helpText() {
        return `Up to ${this.maxSeats} seats`;
    }

    handleChange(event) {
        const value = Number(event.target.value);
        this.dispatchEvent(new FlowAttributeChangeEvent('selectedSeats', value));
    }

    @api
    validate() {
        if (this.selectedSeats > 0 && this.selectedSeats <= this.maxSeats) {
            return { isValid: true };
        }
        return { isValid: false, errorMessage: `Choose between 1 and ${this.maxSeats} seats.` };
    }
}

<template>
    <lightning-input type="number" label="Seats" value={selectedSeats}
        field-level-help={helpText} onchange={handleChange}></lightning-input>
</template>

The template only binds properties and a getter. All logic lives in JavaScript.

Where would you use a Platform Event-triggered flow?

Use one when something publishes an event and you want automation to react without being part of the publisher's transaction. For example, an external order system publishes Order_Shipped__e through the API, and a Platform Event-triggered flow finds the matching Salesforce order, updates its status and notifies the account team.

Points worth making:

• The flow runs in its own transaction, after the event is delivered, so a failure in the subscriber doesn't roll back the publisher.
• By default it runs as the Automated Process user, not the user who published the event. Plan record ownership and "Created By" accordingly.
• Events can arrive in batches, so the same bulkification rules apply.
• If the event is published from Salesforce with Publish After Commit, the flow only sees events from transactions that actually committed.

Senior / design

When do you choose Flow, and when do you choose Apex?

I pick Flow when the logic is straightforward, the business wants admins to own it, and it fits the tools well. Same-record field updates in before-save, guided screens, simple related-record creation and scheduled reminders are all good fits.

I pick Apex when I need one or more of these:

• Complex logic or heavy collection processing that's hard to read as a canvas.
• High data volumes where I need precise control over queries and CPU.
• Robust integration handling: retries, custom authentication, payload mapping.
• Real unit tests with assertions on edge cases.
• Recursion control or transaction design that Flow doesn't express cleanly.

The best answer is often "both". Keep the orchestration in Flow, and put the hard part behind an invocable method so admins can still read the process.

What the interviewer is really checking: whether you have criteria, rather than a personal preference for one tool.

How do you design automation on an object that already has triggers and several flows?

First I map what exists, using Flow Trigger Explorer and the trigger handler, and I write down which automation owns which fields. Most production bugs I've seen here are two automations writing the same field. Remember the order: a before trigger overwrites a before-save flow's value.

Then I set rules the team can follow:

• Each field has one owner, whether that's a flow or a trigger.
• Same-record updates go in before-save flows or before triggers, never after-save updates of the same record.
• Every flow has a trigger order and tight entry conditions.
• A bypass mechanism, such as a custom permission or custom setting checked in entry conditions and trigger handlers, so data loads can skip non-essential automation.

Finally, I test the whole object with a bulk DML of 200 records and look at the limits in the debug log.

How do you test and deploy flows safely?

Testing. Flow Builder lets you create flow tests for record-triggered flows, with assertions on the resulting record values. They're useful for quick regression checks. For anything critical, I also write Apex tests that insert or update records in bulk and assert the outcome. That checks the flow, the triggers and the validation rules together, the way production runs them.

Deploying. Flows are versioned, and only one version is active at a time. A deployment adds a version. Whether it arrives active in production depends on your org's process automation settings, and deploying flows as active brings a flow test coverage requirement. Know which setting your org uses before release day.

Rolling back is quick: reactivate the previous version. That's one reason to keep old versions until a release has settled.

How to practise these questions out loud

Reading answers feels like preparation, but interviews test whether you can say them clearly under a little pressure. Here's what works:

1. Answer out loud, then check. Pick a question, give a 60–90 second answer without looking, then compare it with the one above. Note what you missed.
2. Build the scenario questions. In a Developer Edition org, build the Closed Won renewal flow, then break it on purpose. Put an Update Records in a loop and update 200 records with Data Loader or Anonymous Apex, and watch it fail.
3. Open Flow Trigger Explorer on a busy object and explain the run order to a friend or to a recording.
4. Practise the trade-off questions (Flow vs Apex, before vs after-save) by giving one reason for and one against each option. Interviewers trust candidates who can argue both sides.

If you want to build these flows alongside me, Learn lightning flows with me covers screen flows, record-triggered and scheduled flows, HTTP callouts from Flow, Platform Event-triggered flows and Flow Trigger Explorer, all built live in a real org.

Related guides

• Salesforce Flows learning guide: the full topic, in order.
• Salesforce admin roadmap and admin to developer roadmap: where Flow fits in your career path.
• Apex trigger interview questions: the other half of the order-of-execution conversation.
• Async Apex interview questions: for questions about asynchronous paths and Platform Events.
• A 30-day Salesforce developer interview plan: how to schedule all of this.