Platform Limits: Quick Reference

Governor limits exist because Salesforce is multi-tenant — all customers share compute, storage, and network. These limits are not bugs; they are the foundation that enables automatic scaling, zero-downtime upgrades, and enterprise security at commodity pricing. Know them cold.

Per-Transaction Limits (Synchronous)

The limits you hit most often. Memorize the bolded rows.

Resource	Limit	Notes
SOQL queries	100	Most common limit hit — SOQL in loops
Records retrieved (SOQL)	50,000	Per transaction total
SOSL searches	20	Rarely the bottleneck
DML statements	150	DML in loops hits this fast
Records processed (DML)	10,000	Bulk data operations
Callouts	100	Per transaction
Callout timeout	120s total	Max 120s per individual callout
CPU time	10,000 ms	Complex Flows + Apex chains
Heap size	6 MB	Large collections or JSON payloads
Future calls	50	Per transaction
Queueable jobs	50	Per transaction
EventBus.publish	150	Per transaction
Email invocations	10	Per transaction

Per-Transaction Limits (Asynchronous)

Async gets higher limits — use this when sync limits are not enough.

Resource	Sync Limit	Async Limit	Multiplier
SOQL queries	100	200	2x
CPU time	10,000 ms	60,000 ms	6x
Heap size	6 MB	12 MB	2x
Records retrieved	50,000	50,000	Same

Per-24-Hour Org Limits

Resource	Limit	Notes
API calls	100,000+ (base + per-user)	Soft limit; not immediately blocked
Async Apex executions	250,000 or 200 x licenses	Whichever greater
Batch Apex jobs	100 queued/active	Concurrent
Scheduled Apex jobs	100	Concurrent
Platform Events	~100K/day (varies)	Based on entitlement
Outbound emails (single)	5,000	Per org per day
Mass emails	5,000 external recipients/day (per-blast: 500 EE, 1,000 UE)	Daily cap shared with single email; per-blast limit varies by edition

The 4 limits CTAs hit most

100 SOQL per sync transaction — bad code or AppExchange packages querying in loops
10,000 DML records — bulk data operations exceeding per-transaction limit
API calls per 24 hours — integration-heavy architectures burning through allocation
CPU time (10s sync) — complex Flow automation chains with nested subflows

On-Platform vs Off-Platform Decision

Default: on-platform. Only go off-platform when you can name the specific constraint.

flowchart TD
    A[New capability] --> B{Primarily for<br/>SF users?}
    B -->|Yes| C{Within governor<br/>limits?}
    B -->|No| D[Off-platform +<br/>SF API]
    C -->|Sync OK| E{Declarative?}
    C -->|Async OK| F[On-platform<br/>Async Apex]
    C -->|Exceeds even async| D
    E -->|Yes| G["On-platform<br/>Declarative (Flows)"]
    E -->|No| H[On-platform<br/>Apex + LWC]

    style G fill:#2d6a4f,color:#fff
    style F fill:#457b9d,color:#fff
    style H fill:#457b9d,color:#fff
    style D fill:#9d0208,color:#fff

Go Off-Platform When	Example
Processing exceeds async limits	ETL of 100M records nightly
Long-running computation (minutes-hours)	ML model training
Complex UI beyond Lightning	Consumer-facing app with AR
Real-time streaming at scale	IoT sensors, Kafka-level throughput
Specialized compliance	PCI DSS card processing
Heavy computation	Image/video processing, NLP

The 5x rule

Off-platform maintenance cost is 3-5x initial development over 5 years. Always include this in TCO when recommending off-platform. On-platform, Salesforce absorbs infrastructure, security, and upgrade costs.

Async Pattern Quick Ref

Pattern	Max Time	State	Chaining	Best For
Future Method	60s	No (primitives only)	No	Simple fire-and-forget
Queueable Apex	60s	Yes (serializable)	Yes (default depth 5, configurable via AsyncOptions — Spring ‘25+)	Complex async with state
Batch Apex	60s/batch	Limited (Stateful)	Yes (via finish)	Large data: thousands to millions
Schedulable	N/A	N/A	Invokes others	Time-based scheduling

flowchart TD
    A[Need async] --> B{Data volume?}
    B -->|Small| C{Need state<br/>or chaining?}
    B -->|Large: thousands+| D[Batch Apex]
    C -->|No| E[Future Method]
    C -->|Yes| F[Queueable Apex]

    style E fill:#2d6a4f,color:#fff
    style F fill:#457b9d,color:#fff
    style D fill:#9d0208,color:#fff

Prefer Queueable over Future

Queueable Apex is the modern replacement for Future methods. It supports complex objects (not just primitives), chaining, and monitoring via AsyncApexJob. Default to Queueable unless simplicity is the only goal.

Platform Events & CDC

Feature	Platform Events	Change Data Capture
Event source	Custom (you define)	Automatic (record changes)
Payload	Custom fields	Changed fields (delta)
Use case	Business events, cross-system notifications	Near-real-time data sync
Retention	72 hours (high-volume; standard-volume being retired)	72 hours
Subscription	Apex triggers, Flow, CometD, gRPC	Same as Platform Events

Use CDC for record-change-driven integration (replaces polling). Use Platform Events for custom business events decoupled from record changes.

Big Objects & Custom Metadata

Feature	Big Objects	Custom Metadata Types	Custom Settings
Purpose	Massive data storage (billions)	Configuration/mapping data	Per-user/profile settings
Storage	Separate from standard	Metadata (no storage impact)	Data storage
Queryable	Standard SOQL on indexed fields (Async SOQL retired Summer ‘25)	getInstance (no SOQL limit)	getInstance (no SOQL limit)
Reporting	Not in standard reports	N/A	N/A
Deployable	N/A	Yes (change sets, packages)	No (must load per env)
Triggers	No	N/A	N/A

Default to Custom Metadata Types

For configuration data (feature flags, mapping tables, app config), always recommend Custom Metadata Types over Custom Settings. Key advantage: they deploy through change sets and CI/CD pipelines like metadata, not data. Custom Settings require manual loading in each environment.

Agentforce Architecture (2025-2026)

New platform capabilities to be aware of for current CTA scenarios:

Component	What It Does	Architectural Impact
Agentforce Builder	Low-code agent creation	Declarative AI, no custom ML infra needed
Atlas Reasoning Engine	AI reasoning (2x relevance, 33% more accurate)	On-platform AI processing
Agentforce Voice	Natural language voice interactions	Replaces custom voice integrations
Data Cloud (Data 360)	Unified data ingestion + harmonization	Grounds AI agents in enterprise data
Intelligent Context	Unstructured data understanding	Reduces need for external NLP

Agentforce for CTA scenarios

When a scenario mentions AI, chatbots, or autonomous agents, Agentforce is the platform-first answer. It replaces the need for external AI/ML infrastructure in many cases. Frame as: “Agentforce provides on-platform AI capabilities, avoiding off-platform ML infrastructure costs.”

Data & Storage Limits

Resource	Limit
Custom objects	200 (EE) / 2,000 (UE/PE)
Fields per object (custom)	500
Record size	~8 KB per record
Formula field size	5,000 characters compiled
SOQL query length	100,000 characters

Anti-Patterns to Avoid

Anti-Pattern	Why It Breaks	Fix
SOQL in loops	Hits 100 query limit at ~100 iterations	Query once, use maps
DML in loops	Hits 150 DML limit fast	Collect records, single DML
Sync callouts for batch data	Blocks user, timeout risk	Async callouts or batch
Hard-coded IDs	Breaks across environments	Custom Metadata or Schema class
No error handling on integration	Silent failures, data gaps	Error queue + monitoring
Polling for changes	Wastes API calls	CDC or Platform Events
Wide objects (300+ fields)	Performance, maintainability	Split into related objects

Reverse-Engineered Use Cases

Scenario 1: Logistics company needs to process 50M shipment records nightly from ERP, update Salesforce accounts with delivery metrics.

Decision: Off-platform ETL (MuleSoft or Informatica) + Bulk API 2.0 into Salesforce
Why: 50M records exceeds any on-platform batch processing in a reasonable window. Bulk API 2.0 handles large data loads efficiently.
On-platform complement: Batch Apex for post-load processing (rollup calculations, notifications) in chunks of 200.
Trade-off: Off-platform ETL requires infrastructure management. Mitigate with MuleSoft (Salesforce-owned, managed runtime).

Scenario 2: Retail company wants real-time inventory visibility in Salesforce from their warehouse management system.

Decision: Platform Events for near-real-time inventory updates. Warehouse system publishes events via API. Apex trigger or Flow subscribes and updates inventory records.
Why: Platform Events provide near-real-time without polling (no wasted API calls). Within daily event entitlement for typical inventory update volumes.
Trade-off: At-least-once delivery means potential duplicates. Mitigate with idempotent processing (check external ID before insert).

Scenario 3: Financial services firm needs 10-year audit trail for all field changes on Account and Contact objects.

Decision: Shield Field Audit Trail (retains up to 10 years)
Why: Standard field history tracking only retains 18 months. Regulatory requirement demands 10 years. Field Audit Trail is purpose-built for this.
Alternative considered: Custom audit object with triggers. Rejected because it consumes data storage, requires custom development, and is harder to query than the native Field Audit Trail.
Trade-off: Shield is an add-on cost ($25/user/month) unless on Performance Edition.