In one sentence: a schedule-triggered flow runs on a clock you set, optionally against every record matching a filter, in system context, in batches, with nobody watching. It is the right tool for nightly housekeeping and overdue-record sweeps, and the wrong tool for anything that needs to happen promptly after a record changes, which is what record-triggered flows and their scheduled paths are for.
Setting the schedule
Create a flow and choose Schedule-Triggered. The Start element asks for a start date, a start time, and a frequency of once, daily or weekly. That is the whole scheduler. There is no cron expression, no “first Monday of the month”, and no multiple times per day from one flow.
The time is interpreted in the org’s default time zone, not the running user’s. A flow scheduled for 02:00 runs at 02:00 in the org’s zone year round, so its relationship to local time shifts when daylight saving changes.
The object filter changes everything
Below the schedule you can optionally choose an object and set filter conditions. This is the single most consequential setting on the element.
Leave it blank and the flow runs once per scheduled time, with no $Record. That is the shape for a flow that does its own Get Records and processes collections, and it is the one I reach for by default because it gives you full control over queries, batching, and what happens when nothing matches.
Set an object and filter, and Salesforce queries the matching records and runs a separate interview for each one, with $Record populated. Convenient, and it hides the record count from you until a job runs long.
Batch behaviour and limits
Records matched by the object filter are processed in batches rather than all at once. Each batch is its own transaction with its own governor limits, so a Get Records inside the flow costs one query per record, not one per batch.
The important limit is not per transaction, it is per day. Salesforce caps the number of asynchronous and scheduled flow interviews an org can run in a 24 hour period, and the cap is derived from your licence count. A flow with a loose filter matching hundreds of thousands of records can consume the org’s allowance and starve other automation, so check the current figure for your org in the flow limits documentation before you build a sweep over a large object.
There is no way to cap the number of records the object filter picks up. The filter is the only lever, which is an argument for the no-object approach where a Get Records with a limit and a Collection Sort gives you an explicit ceiling.
Making a sweep idempotent
A scheduled flow has no memory. It does not know which records it processed last night, so it will pick up the same records tomorrow unless the work itself changes them.
Build the state in. A date/time field stamped when the flow processes a record, excluded in the filter next run, is the standard answer. A checkbox works for one-shot processing. Either way, stamp the record in the same update as the rest of the work so a failure does not mark it done.
Test what happens when the flow runs twice in a day, because sooner or later someone will run it manually while investigating something.
Confirming it actually ran
Activating a scheduled flow creates an entry visible in Setup under Scheduled Jobs, which is where you confirm the schedule took effect and when it next runs. Deactivating and reactivating the flow is how you change the schedule. Edits to an active flow’s schedule do not apply retroactively.
For evidence the run did something, do not rely on error emails. Emails only arrive when something fails, so a flow that silently matched zero records looks identical to one that is not scheduled at all. Write a run-log record at the start and end of each run, with counts. It costs one DML statement and it turns “did last night’s job run?” into a report.
Frequently asked
Can I run a scheduled flow on demand? Not directly. Move the logic into a subflow that an autolaunched flow can also call, then trigger that from a button or from Apex when you need to.
Can it do callouts? Yes, provided the callout happens before any DML in that interview. Ordering matters more here than in most flows.
What happens to records added after the job started? The record set is determined when the job begins. New records wait for the next run.
