Updated October 7, 2026
Your sales team closes a major deal. The contract triggers automation that updates opportunity records, creates tasks, sends notifications, and syncs data to your enterprise resource planning system. Everything works perfectly, until it doesn’t. One morning, critical automation fails. Orders sit unprocessed. Your team scrambles to understand why a platform you pay good money for just stopped working.
The culprit: governor limits. Salesforce imposes strict boundaries on how much processing your organization can consume within a single transaction. These limits protect the multi-tenant architecture that makes Salesforce affordable, but they create real constraints that affect how you build processes and grow your business.
What Governor Limits Actually Mean for Your Business
Salesforce runs thousands of organizations on shared infrastructure. Without controls, one company’s runaway process could degrade performance for everyone else. Governor limits act as circuit breakers. They count everything your code and automation consume (database queries, email sends, processing time) and shut down any transaction that exceeds defined thresholds.
A typical transaction might need to query customer records, update opportunity amounts, send confirmation emails, and log activities. Each action consumes part of your allotted budget for that transaction. Run a complex automation at month-end when sales reps mass-update hundreds of records simultaneously, and you can hit these limits fast.
The business impact manifests in three ways. First, critical processes fail. An integration that worked fine with 50 daily orders breaks when you scale to 500. Second, you pay developers and consultants to architect workarounds instead of building features that differentiate your business. Third, you face hard choices about which automations to keep and which to sacrifice as you grow.
The Limits That Matter Most
Salesforce enforces dozens of governor limits, all listed in the Apex Developer Guide’s Execution Governors and Limits page. Five affect most organizations in measurable ways. A sixth, CPU time, is worth knowing too: the same page caps it at 10,000 milliseconds for synchronous transactions and 60,000 for asynchronous ones, and heavy automation on a single save can reach it.
SOQL Query Limits
Salesforce allows 100 database queries per transaction in synchronous operations (when a user clicks a button) and 200 in asynchronous operations (background jobs). Across all of those queries, a transaction can retrieve 50,000 records in total. This sounds generous until you consider common scenarios. A single record save might run several record-triggered flows and Apex triggers, plus automation on related records those updates touch, each potentially executing its own queries from the same budget.
Say an org builds a custom pricing engine that checks product catalogs, discount matrices, and customer contract terms, querying each one per line item. A quote with a handful of lines is fine. A complex deal with 15 or more line items can push the transaction past 100 queries. The fix is restructuring the pricing data model so the engine queries each source once and works from collections in memory, which is far cheaper to do before launch than after.
DML Statement Limits
Data Manipulation Language operations (creating, updating, or deleting records) cap at 150 DML statements per transaction. Organizations that process orders with many line items, or sync data from external systems in batches, hit this ceiling regularly.
Say an org integrates its warehouse management system with Salesforce to update inventory levels, and the first design updates each product record individually. A shipment with 200 items means 200 separate update statements, and the integration fails. Rebuilding it to update records in bulk solves the problem, but building it that way from the start avoids the delay entirely.
Heap Size Limits
Heap is the memory a transaction can use. As of Winter ‘27, the Apex Developer Guide lists total heap size at 10 MB for synchronous transactions and 25 MB for asynchronous ones. When this post was first published, the limits were 6 MB and 12 MB, so orgs on the new release have more room than before. Complex calculations, large data sets held in memory, or poor code design can still exhaust it.
Say an org builds custom reporting that pulls three years of client transaction data into memory for analysis. It works in testing with sample data, then fails in production where some clients have thousands of transactions. The fix is processing the data in smaller chunks, for example with Batch Apex, rather than loading everything at once. A higher limit buys headroom, not immunity: data volume keeps growing.
API Call Limits
Each time an external system queries or updates Salesforce through the API, it consumes one call from a rolling 24-hour allocation. The allocation depends on your edition and licenses. Per the API Request Limits and Allocations page, a Developer Edition org gets 15,000 calls, while an Enterprise Edition org gets 100,000 plus a per-license amount (1,000 per Salesforce license) plus any purchased API call add-ons. Salesforce’s own example: an Enterprise Edition org with 15 Salesforce licenses gets 115,000 calls.
Say an org connects its e-commerce platform, marketing automation tool, and customer service system to Salesforce, and each one polls for changes record by record. Usage creeps up as each integration is added, and nobody looks at the total until it’s close to the ceiling. Buying add-on capacity is one option. The longer-lasting fix is re-architecting the integrations to batch their requests, so the same work takes far fewer calls.
Email Send Limits
Each org can send single emails to a maximum of 5,000 external email addresses per day, based on GMT. For orgs created in Spring ‘19 or later, that limit also covers email alerts, simple email actions, and Send Email actions in flows, not just emails sent through Apex and the API. Mass email is not a way around it: mass email and list email also max out at 5,000 external addresses per day per org.
Say a property management company automates tenant communications with flows. As its portfolio grows, peak periods like lease renewals push daily sends to external addresses past 5,000, and the remaining emails fail. At that volume, moving high-volume communication to a dedicated email platform is usually the right call, with Salesforce triggering it rather than sending everything itself.
Why These Limits Exist and What They Cost You
The multi-tenant model makes Salesforce viable at its price point. Without it, small and mid-market companies couldn’t afford enterprise-grade CRM infrastructure. But the model shifts certain infrastructure costs back to you as the customer.
When your business processes bump against limits, you have three options. You can simplify processes and lose functionality that provides competitive advantage. You can invest in technical optimization, paying developers to make code more efficient. Or you can purchase additional capacity where Salesforce offers it, like API call add-ons.
Most organizations end up doing some of all three. And much of the customization and integration work in a growing org involves designing around governor limits.
The hidden cost appears in foregone opportunities. When your technical team spends weeks optimizing batch jobs to stay within heap limits, they’re not building the custom analytics dashboard your sales leadership requested. When you simplify automation to avoid DML limits, you lose data quality controls that reduce downstream errors.
Designing for Scale From the Start
Organizations that manage governor limits successfully plan for them during initial implementations. They adopt several practices that prevent expensive refactoring later.
They design processes to handle records in bulk rather than one at a time. A process built to update five opportunity records today will eventually need to update 50 or 500. Building bulk handling from day one costs marginally more during implementation and saves far larger remediation projects later.
They establish clear governance for who can build automation and what standards they must follow. When individual business units create their own automation without coordination, overlapping processes compound quickly and push against limits. If your org still runs Workflow Rules or Process Builder, note that Salesforce ended support for both on December 31, 2025 and recommends migrating to Flow. Say an org finds well over a hundred overlapping rules, processes, and flows on its core objects. Migrating them is a natural moment to consolidate into a smaller set of well-conditioned flows and remove the redundant work that drives limit errors.
They monitor limit consumption proactively. Salesforce provides tools to track how close your processes come to various limits. Organizations that review this data regularly catch problems while they’re still manageable. Say a quarterly review shows an org using most of its daily API allocation, with two new integrations planned. That is the time to optimize existing integrations or buy capacity, before launch rather than during an outage.
They separate critical and nice-to-have automation. When you must make tradeoffs, knowing which processes directly affect revenue or customer experience guides decisions. Say an org running up against its daily email limit has to choose: customer-facing shipment notifications should win over internal notification emails, so the functions customers see stay reliable.
The Bottom Line
Governor limits represent a fundamental tradeoff in the Salesforce model. You gain affordable access to enterprise infrastructure by accepting constraints on resource consumption. These constraints rarely matter when you first adopt Salesforce, but they become strategic concerns as you grow and integrate more systems.
Plan for them. During implementation, pressure your consulting partner to demonstrate how their design handles volume. Ask specific questions: What happens when we process 500 orders instead of 50? How close to limits will we run at twice our current transaction volume?
Budget for them. Set aside a standing portion of your annual Salesforce budget for optimization work and capacity purchases. Governor limit remediation often happens in urgent situations, when processes are already failing. Having budget allocated makes those conversations less contentious.
Measure them. Include limit monitoring in your quarterly platform health reviews. Identify concerning trends before they become outages. An outage during month-end close can easily cost more than the monitoring that would have caught it.
Governor limits will never feel like a feature. They constrain what you can build and force technical complexity into what should be simple business processes. But they’re the price of multi-tenancy. Understand them, plan for them, and design with them in mind from the start. The organizations that do avoid expensive surprises and build Salesforce implementations that scale with their growth.