Salesforce Org Limit and Capacity Governance
Overview
Treat limits as shared, time-varying org contracts and allocate headroom across integrations without publishing fixed universal thresholds.
Prerequisites
- Authorized org, workload, API and event modes, business priority, and peer integrations
- Current Limits resource, Sforce-Limit-Info, job, event-usage, and application telemetry
- Platform, integration, incident, and business owners with a deferral policy
Tool Discipline
Use Read, Glob, and Grep to inspect approved repository and evidence files, WebFetch to re-check current first-party Salesforce documentation, and Write or Edit only for secretless plans, fixtures, configuration, and redacted receipts.
Current Contract
The versioned Limits REST resource returns maximum and remaining allocations and can lag consumption by up to five minutes. Sforce-Limit-Info reports REST API usage; names, allocations, windows, grace behavior, and entitlements vary by org, edition, license, API version, and workload.
Authentication
Use an approved read-only principal with the permission required to view limits. Do not expose tokens, org identifiers, or unrelated allocation details in public metrics or receipts.
Instructions
- Inventory every workload sharing the org, its API mode, priority, schedule, concurrency, retry behavior, and owner.
- Discover a supported API version and capture current Limits and response-header evidence with timestamps.
- Map relevant REST, bulk, async, Apex, storage, and event allocations to workloads and business deadlines.
- Model normal, burst, retry-storm, backfill, and incident demand with an explicit measurement-lag safety margin.
- Define admission, concurrency, batching, backpressure, deferral, and stop policies per priority class.
- Test the policy with synthetic work in an authorized non-production org and prove hard exhaustion is not blindly retried.
- Monitor actual usage and reconcile deferred work; review allocations and policy after releases, license changes, and incidents.
Approval Boundaries
Do not consume production capacity for testing, raise concurrency, defer critical work, purchase capacity, or disable peer integrations without accountable owners.
Output
Return the dated allocation snapshot, workload budget, scenarios, safety margin, controls, alerts, deferred-work ledger, and review owner.
Error Handling
| Condition | Response |
|---|---|
| Limits values change between reads | Use timestamps and the documented measurement lag; avoid rapid concurrent reads as a consistency oracle. |
| Hard allocation is exhausted | Stop admission and reconcile pending work; exponential backoff alone cannot create capacity. |
| Workload ownership is unknown | Do not assign it shared capacity until an owner and priority are established. |
Example
A redacted completion receipt might look like this:
org=production; resources=rest+bulk+events; snapshot=dated; margin=owner-approved; admission=active; deferred=42; blind-retry=off
Resources
Next Steps
Run the workflow first in the lowest-risk authorized org and preserve its redacted receipt. Schedule a review against the next Salesforce seasonal release and the customer change calendar.