Interview
An Interview in Salesforce is the runtime instance of a flow, the live execution that the platform spins up each time a flow runs.
Definition
An Interview in Salesforce is the runtime instance of a flow, the live execution that the platform spins up each time a flow runs. The flow definition you build in Flow Builder is the blueprint. The Interview is one specific run of that blueprint, with its own variable values, its own pointer to the current element, and its own running user. The full name in the documentation is Flow Interview, and the two terms are used interchangeably.
Most interviews finish in milliseconds and never touch the database. The ones that pause stick around as rows in the FlowInterview standard object. A screen flow stopped at a Pause element, an autolaunched flow holding at a Wait, or a record-triggered flow with a scheduled path all leave a paused interview that an admin can find, resume, or delete under Setup. The same concept surfaces in Apex through the Flow.Interview class, which lets code launch a flow and read back its outputs.
How an Interview runs, pauses, and gets cleaned up
Definition versus interview
The cleanest way to hold this in your head is blueprint versus build. The flow definition is the metadata record you see in Setup under Flows. It does not run anything on its own. The Interview is what runs. Every fire of a record-triggered flow on a save creates one Interview. Every launch of a screen flow by a user creates one Interview. Every autolaunched flow invoked from Apex or a process creates one Interview. Each one carries its own copy of the variables, so two interviews of the same flow never share state. The Interview also tracks which element is executing right now and which user the flow runs as. That running user matters, because it decides record visibility and which fields the flow can read or write. When people say a flow "ran 4,000 times yesterday," what they mean is that the platform created 4,000 interviews of that one definition. The distinction is not academic. It is the difference between editing logic once and watching that logic execute thousands of independent times.
When an interview persists
The default lifespan of an interview is the transaction that spawned it. It starts, walks its elements, and disappears the moment the work is done. Three situations change that. A screen flow that hits a Pause element saves its full state and parks itself so the user can come back later. An autolaunched or record-triggered flow that reaches a scheduled path or a Wait condition pauses until the clock or the event catches up. In all three cases the platform writes a row to the FlowInterview standard object to hold the saved variables and the current element. Those rows are what you see under Setup, in Paused and Waiting Interviews, and what a user sees in the Paused Interviews component on the Home page. A persisted interview is a real database record. It counts against org limits, it can be queried, and it does not vanish until someone resumes it, the wait fires, or an admin deletes it.
Bulk DML multiplies interviews
This is the single most important thing to understand about interviews if you write record-triggered flows. Insert 200 records that match a flow entry criteria in one operation, and the platform creates 200 interviews inside a single Apex transaction. All of them share that transaction governor budget. The same 100 SOQL queries, 150 DML statements, and 10 seconds of CPU cover every interview together, not each one separately. A flow that runs a query or a DML inside a loop element looks fine when you test it by saving one record by hand. Load 200 rows through Data Loader and the same logic multiplies the query count past the limit, and the whole transaction rolls back. Most production flow failures trace back to this gap between single-record testing and bulk behavior. The fix is to keep queries and DML outside loops, and to test with at least 200 records before you trust a flow in production.
Resuming a paused interview
A paused screen flow waits for someone to finish it. Users find their own paused interviews in the Paused Interviews list on the Home page, and clicking Resume reloads the flow exactly where it stopped, with every variable already restored. Nothing is recomputed, the saved state is simply rehydrated. Admins can resume an interview on behalf of a user from Setup. That is handy when an employee leaves or a process stalls, but it carries a real consequence. Resuming changes the running user for the rest of the interview, which shifts the record access and the field-level security the flow operates under. A flow that could see a record when the original user paused it might behave differently when an admin resumes it as themselves. You can also surface a resume button on a record page with a custom component and the paused interview ID, so users restart the right interview straight from the record it belongs to instead of hunting through a generic list.
Launching a flow from Apex
When Apex needs to run a flow, it goes through the Flow.Interview class. The pattern is short. You build a map of input variables, call Flow.Interview.createInterview with the flow API name and that map, then call start on the returned object. The flow then runs inside the same Apex transaction that created it, sharing the caller governor limits. The class lets you pass strongly typed inputs in and read output variables back out once the flow completes, which is cleaner than threading untyped values through an invocable action. This matters for trigger handlers and batch jobs that want flow logic without rebuilding it in Apex. One caution worth remembering: a flow started this way still counts as an interview against the transaction, so a batch that launches a flow per record is subject to the same bulk pressure as a record-triggered flow. Use it when you want declarative logic callable from code, not as a way to dodge limits.
Debugging and logging interviews
Flow Builder ships a Debug feature that simulates one interview against the live org. It shows the value of every variable at each step, the exact path the interview took through decision elements, and the query counts it racked up. That is the fastest way to see why a single run behaved the way it did. For interviews that already ran in production, set the Flow log category in a debug log and the Apex log captures the same element-by-element trail. Paused interviews show their saved state in Setup, though not the full path they took to get there. Salesforce also offers the FlowInterviewLog object, which records execution details for completed interviews so you can report on flow runs over time. When a flow fails, the unhandled fault goes to the email recipient configured in Process Automation Settings, or to the flow owner if none is set. Pointing that at an admin distribution list, rather than letting errors land on the running user, is one of the first hardening steps on any production flow.
Stale interview cleanup
Paused screen flows do not expire on their own. A renewal wizard a user abandoned six months ago still holds a row in FlowInterview, and those rows accumulate. Left alone, the paused and waiting list grows until it is genuinely hard to tell a live pause from dead weight, and the org can bump into its paused-interview limits. The practical answer is a scheduled cleanup. Build a schedule-triggered flow or a scheduled Apex job that queries FlowInterview for records older than a sensible threshold and deletes them, after checking that nothing downstream still needs the saved state. Some teams instead surface a filtered list view of old interviews so an admin reviews and clears them by hand each month. Either way, treat paused interviews as data that needs a retention policy, the same as any other growing table. Newer org settings have relaxed the hard cap on paused and waiting interviews, but relaxed is not the same as unmanaged, and cleanup still keeps the list usable.
Manage paused and waiting interviews
There is no screen to create an interview, the platform makes one every time a flow runs. What an admin actually manages is the set of paused and waiting interviews. Here is how to find, resume, and tidy them, plus the settings that govern where errors and resume actions land.
- Open the paused and waiting list
In Setup, search for Paused and Waiting Interviews under the Flows area. The list shows each persisted interview, its flow, the user who paused it, and the element it stopped on. This is your single view of every interview currently sitting in the FlowInterview object.
- Resume or delete an interview
Select an interview to resume it on behalf of the user or to delete it. Remember that resuming runs the rest of the flow as the user who resumes it, which can change record access. Delete only after confirming the saved scenario is genuinely abandoned.
- Set the fault email recipient
In Process Automation Settings, set the default workflow user and the email address that receives unhandled flow faults. Point this at an admin or a distribution list so production errors do not silently reach the running user.
- Schedule a cleanup
Build a schedule-triggered flow or scheduled Apex that queries FlowInterview for rows older than your retention threshold and deletes them. Run it monthly so abandoned screen flows do not pile up in the paused list.
The Setup page that shows every persisted interview, with actions to resume or delete each one.
Where the default workflow user and the unhandled-fault email recipient are configured for all flows in the org.
The Home page component that lets each user find and resume their own paused screen flows without admin help.
- Resuming a paused interview changes the running user, so record visibility for the rest of the flow may differ from when it was paused.
- Bulk inserts create one interview per matching record in a single transaction, all sharing one governor budget, so test with at least 200 records.
- Paused screen-flow interviews never expire on their own and will accumulate in FlowInterview until something resumes or deletes them.
Prefer this walkthrough as its own page? How to Interview in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Interview.
- Flow InterviewsSalesforce
- Paused Flow Interview ConsiderationsSalesforce
Hands-on resources to go deeper on Interview.
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 is a Flow Interview in Salesforce automation?
Q2. Which states can a Flow Interview be in across its lifecycle?
Q3. Why does inserting 200 records that match a record-triggered flow risk a Flow Interview hitting governor limits?
Discussion
Loading discussion…