Hitting a Salesforce governor limit mid-deployment is one of those experiences you only want once. Whether you’re an admin planning a new object schema, a developer bulkifying triggers, or an architect scoping an integration, knowing your limits before you build saves hours of debugging later.
This quick reference covers over 100 Salesforce platform limits across every major category — Apex governor limits, SOQL and SOSL constraints, DML rules, API allocations, schema and field limits, Flow and automation caps, email limits, storage, and more. It’s updated against Salesforce’s official developer documentation and kept current with each major release.
Use the category filters to jump straight to what you need, or use the search box to find a specific limit by name. Values flagged in yellow are the ones most commonly responsible for production errors — worth committing to memory.
How Salesforce Governor Limits Work
Salesforce runs on a multitenant architecture — meaning your org shares infrastructure with thousands of others on the same servers. Governor limits exist to ensure no single org can monopolise shared resources like CPU time, heap memory, or database connections. When your code or automation exceeds a limit, Salesforce throws a runtime exception that rolls back the entire transaction.
Some limits are hard — they cannot be raised under any circumstances, and hitting them means rethinking your approach. Others are soft — Salesforce support can increase them on request, or they scale automatically with your user licence count.
The limits that catch people most often:
- 100 SOQL queries per synchronous transaction — the single biggest source of “Too many SOQL queries: 101” errors, almost always caused by queries inside loops
- 150 DML statements per transaction — easy to burn through when triggers cascade across related objects
- 10,000 ms CPU time (synchronous) — complex formula evaluations and nested loops are the usual culprits
- Activity object field limit — raised to 300 in Spring ’25, but still the tightest field cap on any standard object
- Controlling picklist values — capped at 300 by default, which surprises teams building complex dependent picklist hierarchies
Limits vary by edition. Enterprise and Unlimited orgs have significantly higher field and object caps than Professional orgs. If you’re scoping a build for a client, always confirm their edition before designing your data model.
Limits can change between releases. Salesforce publishes three major releases per year (Spring, Summer, Winter). This reference is maintained against the current release — bookmark it and check back after each release cycle.