Automation is now the round where most experienced Salesforce developers lose marks. Panels have stopped asking what a Flow is. They ask which flow type you chose, why it ran before the save instead of after, and what you did when it failed in production at two in the morning. The twenty questions below come from real Salesforce developer interview rounds, grouped the way panels work through the topic: flow types and the save order, asynchronous behaviour, the move off Process Builder, Apex from Flow, then limits and debugging.
Flow types, triggers and the save order
Explain Flow vs Apex.
Both run server side in the same transaction and share the same governor limits. The difference is who maintains the logic and how much control you need.
| Decision criterion | Flow | Apex |
|---|---|---|
| Who maintains it | Admin or developer | Developer only |
| Same-record field update | Before-save flow, cheapest on the platform | Before trigger, costs more to maintain |
| Complex branching across objects | Becomes unreadable quickly | Natural fit |
| Bulk behaviour | Per element, breaks if you put DML in a loop | You control it |
| Callouts | Only via invocable Apex or an async path | Native |
| Error handling | Fault paths and the fault message variable | try/catch with typed exceptions |
| Testing | Debug runs and flow tests | Unit tests with assertions and mocks |
The working rule: start in Flow, move to Apex when the logic needs real data structures, callouts or branching a canvas cannot hold.
Memorised definitions collapse the moment the panel asks for a real project example, so attach a case from your own work where you chose one over the other.
When to use Record-Triggered Flow?
Use it when something must happen because a record was created, updated or deleted, and the logic fits declarative elements: stamping fields on the triggering record, creating a related task, updating a parent, calling an invocable action.
Avoid it when you need a callout in the same transaction, or when the logic must run in a precise order against existing Apex triggers. And do not build one flow per requirement. Five after-save flows on Opportunity run in an order you then manage by hand.
What is Before-Save Flow?
A before-save record-triggered flow runs early in the save order, ahead of before triggers, while the record is still in memory. You assign values directly to the $Record variable and the platform saves them as part of the same write.
Because there is no second save, it does not consume a separate DML statement and it does not send the record back through the save order again. That is the whole performance argument.
The trade-off is a narrow element set. It supports assignments, decisions, loops and Get Records. It cannot call actions, invocable Apex or subflows, and it cannot touch any record other than the one that triggered it.
What is After-Save Flow?
An after-save record-triggered flow runs after the record has been written to the database, within the same transaction. The record now has an Id, related records are reachable, and the full element set is available including actions, invocable Apex and scheduled paths.
The cost is a second DML if you update the triggering record from here, which sends it back through the save order and is the main source of recursion in Flow-heavy orgs.
| Behaviour | Before-save | After-save |
|---|---|---|
| Position in the save order | Before before triggers | After the record is written |
| Update the triggering record | Direct assignment, no extra DML | Update element, extra DML and a second save |
| Create or update other records | Not allowed | Allowed |
| Call an action, Apex or subflow | Not allowed | Allowed |
| Scheduled paths | Not available | Available |
| Record Id available | Only on update and delete | Always |
What the interviewer is actually checking
- Whether you can place both flow types in the save order, not just read the label on the radio button.
- Whether you reach for before-save automatically when the update is on the same record.
- Whether you know what a before-save flow cannot do, which is the real test.
- Whether you understand that the second DML, not the flow itself, is what costs you.
Asynchronous and scheduled execution
What is Asynchronous Flow?
Asynchronous in Flow means the work leaves the current transaction and runs in a new one with a fresh set of limits. An asynchronous path on an after-save flow runs immediately after the triggering transaction commits. A Pause element ends the transaction and resumes the interview when the resume condition is met.
The usual reason to use it is a callout, since you cannot call out in a transaction that has already performed DML. The behaviour to remember is that the original transaction has already committed, so if the asynchronous work fails the record is still saved. Your error handling has to cope with a half-finished process rather than a clean rollback.
What is Scheduled Flow?
A schedule-triggered flow runs on a schedule rather than in response to a record change. You set a start date and time and a frequency of once, daily or weekly. Optionally you point it at an object with filter conditions, and the flow runs once for each matching record with $Record set to that record.
Use it for overnight housekeeping, data quality sweeps or renewal reminders. It runs as an automated background process, so do not write logic that depends on the current user. The limit worth knowing is behavioural rather than numeric: Salesforce caps how many scheduled flow interviews an org runs per day, and a loose filter burns through that allowance.
What is Scheduled Path in Flow?
A scheduled path is a branch on an after-save record-triggered flow that runs at an offset from a date field or from the moment the record changed, such as seven days after Close Date. Each path runs asynchronously in its own transaction with its own limits.
The platform re-checks the record against the entry conditions before running the path, so a record that no longer qualifies is skipped. Pending paths are queued in the org: editing the flow does not change what is already waiting, though pending executions can be reviewed in Setup.
This replaced time-dependent workflow actions, and it is the usual reason a team cannot simply switch off their old Workflow Rules.
What the interviewer is actually checking
- Whether you know asynchronous means a new transaction with fresh limits, not merely "later".
- Whether you can separate a schedule-triggered flow from a scheduled path.
- Whether you think about queued work when the record changes underneath it.
Moving off Process Builder and Workflow Rules
What is Process Builder deprecation impact?
Salesforce has retired Workflow Rules and Process Builder for new development. You can no longer create new ones, existing ones continue to run for now, and Salesforce has published a retirement plan with an end point after which they stop executing. Treat migration as scheduled work with a deadline.
The impact is wider than the tooling. Every field update, email alert and time-dependent action hiding inside old automation has to be found, rebuilt and tested. Time-dependent actions with a populated queue need particular care, because pending actions do not migrate themselves.
How do you migrate PB to Flow?
Salesforce provides a Migrate to Flow tool in Setup under Process Automation. It reads a Workflow Rule or a process and produces a new flow in draft, which you review, test and activate before deactivating the original. It does not convert every action type, and time-dependent actions usually need rebuilding by hand.
- Inventory every active rule and process per object, with its criteria and actions.
- Decide the target design first. Several small processes on one object should converge into one before-save and one after-save flow, not a one-for-one copy.
- Run the tool where it fits and build the rest manually.
- Compare behaviour in a sandbox with real data, including the negative cases where automation should not fire.
- Activate the flow and deactivate the old automation in the same deployment.
Step 5 is the one candidates forget. Running both in parallel "to be safe" gives duplicate records and double emails.
How do you design enterprise automation?
Answer as a design standard rather than a feature list.
- One before-save flow and one after-save flow per object where requirements allow, with internal branching instead of several flows competing for order.
- A naming convention that states object, trigger type and purpose, so Flow Trigger Explorer stays readable.
- Reusable logic in subflows, anything genuinely complex in invocable Apex.
- One error-handling pattern everywhere, with faults logged to a single place rather than emailed to whoever last saved the flow.
- A written rule about where Apex triggers end and Flow begins on shared objects.
Interviewers go five levels deep here: which object, what the requirement was, why you chose this over the alternative, what your own role was. Answer in the shape of Situation, Approach, Reason, Result rather than starting with "basically in our project we had one requirement".
What the interviewer is actually checking
- Whether you know the retirement is real and has a deadline.
- Whether you treat migration as a redesign rather than a copy.
- Whether you can describe a cutover that never runs old and new automation together.
- Whether you work to a standard or build whatever the ticket says.
Reuse, Apex and orchestration
What is Subflow?
A subflow is an autolaunched flow called from another flow through the Subflow element. Variables marked Available for Input receive values from the caller, and variables marked Available for Output pass values back.
It runs inside the same transaction as the calling flow and shares its governor limits, so calling a subflow in a loop is the same mistake as putting a Get Records element in a loop.
A screen flow can call a subflow containing screens; an autolaunched flow cannot. Record-triggered flows are not callable as subflows.
What is Invocable Apex?
Invocable Apex is an Apex method exposed to Flow as an action, marked with the @InvocableMethod annotation. The method must be static, there can be only one per class, and it takes a list and returns a list.
The list is the bulkification contract. When several flow interviews reach the same action in one batch, Flow passes a single list of requests, and your method must return a list of the same size in the same order. Use it when the logic needs a callout or a real data structure.
How do you expose Apex to Flow?
Wrap the inputs and outputs in inner classes whose fields carry @InvocableVariable, and annotate the entry method. The action appears in Flow Builder under the category you give it.
public with sharing class CreditCheckAction {
public class Request {
@InvocableVariable(label='Account Id' required=true)
public Id accountId;
@InvocableVariable(label='Requested Amount' required=true)
public Decimal amount;
}
public class Result {
@InvocableVariable(label='Approved')
public Boolean approved;
@InvocableVariable(label='Message')
public String message;
}
@InvocableMethod(label='Run Credit Check' category='Finance')
public static List<Result> run(List<Request> requests) {
Set<Id> accountIds = new Set<Id>();
for (Request req : requests) {
accountIds.add(req.accountId);
}
Map<Id, Account> accounts = new Map<Id, Account>([
SELECT Id, AnnualRevenue
FROM Account
WHERE Id IN :accountIds
]);
List<Result> results = new List<Result>();
for (Request req : requests) {
Account acc = accounts.get(req.accountId);
Result res = new Result();
res.approved = acc != null
&& acc.AnnualRevenue != null
&& acc.AnnualRevenue >= req.amount;
res.message = res.approved ? 'Approved' : 'Send for manual review';
results.add(res);
}
return results;
}
}
Note the single SOQL query outside the loop. That is the point of the list signature, and it is what panels look for.
What is Flow Orchestration?
Flow Orchestration handles multi-step, multi-user processes that run over time rather than inside one transaction. An orchestration contains stages, each stage contains steps, and a step is either interactive, assigning a screen flow to a user or queue as a work item, or background, running an autolaunched flow.
Use it for handoff-style processes where different people own different stages, such as employee onboarding. A screen flow cannot span multiple users across several days; an orchestration can, because each step holds its own state. Orchestration runs are usually licensed separately, so confirm entitlement before designing around it.
What the interviewer is actually checking
- Whether you know a subflow shares the caller's transaction and limits.
- Whether you can explain why
@InvocableMethodtakes a list. - Whether your Apex example queries outside the loop.
- Whether you can say when Apex is the right answer instead of defending Flow for everything.
Limits, errors and debugging
What is Flow Transaction Model?
A flow does not get its own governor limits. It runs inside the transaction that started it and shares every limit with the triggers, classes and other flows there. A Get Records element is a SOQL query. A Create or Update element is a DML statement. Put either inside a loop and each iteration costs one more.
Flow bulkifies automatically across interviews: when a record-triggered flow processes a batch and the interviews all reach the same element, the platform groups that element's database work into one operation. A loop inside a single interview gets no such help.
Anything that ends the transaction gives you fresh limits. A Pause element, an asynchronous path and a scheduled path each resume in a new transaction, the correct way to break up heavy work.
What is Flow Error Handling?
Every element that touches the database or calls an action can fail, and each one can carry a fault connector to a fault path. Inside the fault path, the $Flow.FaultMessage global variable holds the platform's error text.
Without a fault path, the default differs by flow type. A screen flow shows an unhandled fault screen. A record-triggered or autolaunched flow rolls the transaction back, blocks the save, and emails the flow's last modifier unless the org has redirected it in Process Automation Settings.
One senior-level point earns marks. If your fault path writes an error record in the same transaction and that transaction then rolls back, the error record goes with it. The usual pattern is to publish a platform event from the fault path, because published events survive the rollback.
How do you debug Flows?
Flow Builder has a Debug button. It runs the flow with inputs you supply, shows the path taken element by element with variable values, and for record-triggered flows lets you pick a real record and roll back the changes afterwards. Beyond that:
- Debug logs with the Workflow category raised, which show each element and its inputs.
- The Paused and Failed Flow Interviews page in Setup.
- The flow error email, which names the failing element and the variable state at the time.
- Flow tests on record-triggered flows, which let you assert the outcome.
Candidates fail on demonstration rather than knowledge, and "your flow is not firing, what do you check" separates them faster than any definition. Have the checklist ready: is the version active, do the entry conditions match, is the field you are testing actually changing, is something else blocking the save.
How do you optimize Flow performance?
- Move same-record field updates to a before-save flow. This removes an entire save cycle.
- Set entry conditions narrowly, and use the option that runs the flow only when a record is updated to meet the condition requirements.
- Never put Get Records, Create, Update, Delete or a subflow inside a loop. Build a collection in the loop and act on it once outside.
- In Get Records, select only the fields you need and store only the first record when that is all you use.
- Move long-running work and callouts to an asynchronous or scheduled path.
Recursion is the other half of this answer, because a flow that re-triggers itself is the most expensive flow in the org. Use before-save for same-record updates so there is no second save. Set entry conditions with Is Changed on the specific field, or fire only when the record newly meets the criteria. Never let flow A update a record that triggers flow B, which updates the record that triggers flow A. For circular requirements, use a static Boolean in an Apex class exposed as an invocable action. The platform stops a runaway transaction eventually, but by then the user has seen a failed save.
How do you version Flows?
A flow is a container with numbered versions. Only one is active at a time. Activating a new version deactivates the previous one, and you cannot edit an active version, so any change is saved as a new version.
Interviews already running finish on the version they started on, which matters for paused interviews waiting on a resume condition. Reactivating an earlier version is the fastest rollback available in production.
Deploying a flow in active status to production is subject to a flow test coverage requirement, which is why some teams deploy inactive and activate by hand.
What is Flow Trigger Explorer?
Flow Trigger Explorer is the Setup page that lists every record-triggered flow for a selected object, grouped by when it runs: before save, after save and before delete. It shows the order in which they execute and lets you activate or deactivate them from one screen.
Its real value is the trigger order. You assign each flow an order number and they run from the lowest upward; flows without a number run after those that have one, in an order you cannot rely on.
Use it as an audit tool. Before touching automation on an unfamiliar object, see what is already there, because the flow that breaks your change is usually the one nobody documented.
What the interviewer is actually checking
- Whether you know Flow shares limits with everything else in the transaction.
- Whether you know why a fault path that writes a record can lose that record.
- Whether you treat trigger order as something to set rather than hope about.
- Whether recursion is something you design against or something you fix after go-live.
Preparing for the automation round
Flow questions reward people who have built things and broken them. The answers give you the structure; credibility comes from the example you attach to each one: the object, the requirement, the decision, the result. Write two or three out and rehearse them.
If you want the practice rather than the reading, the Salesforce training in Pune with placement support at RizeX Labs builds the automation module in live orgs, with flows, invocable Apex and fault handling built by hand rather than watched on a slide.