Governor Limits are Salesforce's per-transaction caps that prevent any one user or job from monopolising the multi-tenant infrastructure. They apply uniformly to every transaction — flow, trigger, batch, anonymous Apex, integration call.
The ones admins encounter most:
- SOQL queries per transaction — 100. A flow with a Get Records inside a loop is the most common way to blow this.
- DML statements per transaction — 150. Each Update/Create/Delete element in a flow counts.
- Records processed per transaction — 10,000 for synchronous DML. Flows updating 10k+ rows in one go fail.
- CPU time per transaction — 10,000 ms (10 seconds). Long flows with many decisions, complex formulas, or recursive subflows hit this. Heavy validation rules contribute too.
- Heap size — 6 MB sync, 12 MB async. Loading 100,000 records into a flow collection variable can exceed this.
- Email invocations per transaction — 10 single-recipient or 1 mass email. Send-Email actions in flows that loop over results blow it.
- Async jobs queued per 24 hours — 250,000 by default. Heavy schedule-driven orgs near this limit.
Beyond per-transaction:
- Storage limits — data storage and file storage caps per edition. Not a transaction-time limit, but a real constraint.
- API call limits — 24-hour API call total per org. Integration-heavy orgs monitor this.
Practical admin habits:
- Always bulk-design flows: Get Records once outside the loop, build a collection, update with one Update Records action.
- Use before-save flows to update fields on the same record — they save SOQL and DML compared to after-save.
- Schedule-trigger flows that process 10,000s of records need batching (Decision element + Loop with Set Variable).
- Watch Limits in production via Event Monitoring or via Setup -> System Overview.