Which governor limit breaks first when you text 50,000 contacts from Salesforce, and the asynchronous architecture that keeps bulk sends inside the limits.
Salesforce is a shared cloud platform. Thousands of organizations operate on the same underlying infrastructure at the same time. Things usually go well most of the time. But shared infrastructure comes with a challenge: how do you ensure that one organization's code doesn't consume more than its intended share of resources? A query-heavy code kicks off an automation. Records begin piling up, and resource consumption climbs. Left unchecked, a single transaction could consume resources far beyond what it should be allowed.
Salesforce doesn't leave that to chance. This is where governor limits come in. They set boundaries on how much a transaction can consume, from SOQL queries and database operations to CPU time and memory. But here's the catch: your code can be logically correct and still fail if it crosses one of these boundaries. In Salesforce, getting the job done is only part of the equation. You also need to get it done within the limits. For teams running high-volume messaging campaigns, Salesforce bulk SMS limits are where that constraint becomes impossible to ignore.
What Governor Limits Actually Mean for SMS
Governor limits in Salesforce are per-transaction enforced boundaries. Not warnings or soft caps that slow things down. Hard stops that roll back the transaction when crossed — which in a messaging context means records that were mid-process do not send, do not retry automatically, and do not log consistently enough to know exactly which ones failed.
The limits that matter for bulk messaging are not all the same type. Some are per-transaction. Some are per-request. Some are daily org-wide. Understanding which limit a failure traces to changes the fix entirely — which is why governor limits SMS failures diagnosed as a single problem almost always come back after the first attempted fix.
Per-transaction limits that surface first in SMS workflows:
Data Manipulation Language (DML) Statements: 150 per Transaction
Salesforce allows up to 150 DML statements in a transaction. These are database operations that create, update, or delete records.
Consider an SMS workflow that retrieves a Contact, updates its send timestamp, creates an Activity record, and changes the Contact’s Campaign Member status. That’s four database write operations for each record. The process involves 40 records in one trigger, and the workflow requires 160 operations. However, Salesforce permits only 150, meaning that the transaction will fail to complete the entire process for 40 records. The messages in the process may fail to send, and the records may not be updated as well. Recovery depends on how the workflow handles errors and retries.
Salesforce Object Query Language (SOQL) Queries: 100 per Transaction
Salesforce allows up to 100 SOQL queries per transaction, with a separate limit of 50,000 rows returned.
A single query in a loop is executed once for each row. For example, if there are 50 rows, 50 queries will be executed. With 101 queries, the transaction would exceed the limit and therefore fail. The row limit poses another issue. There could be a query exceeding the row limit of 50,000 rows, while performing a query only uses 1 query out of the 100-query limit. Here, the problem is not too many queries; it is one query fetching too many rows that exceed the row limit.
Callouts: 100 per Transaction
An outbound SMS API request is a callout because it sends a request from Salesforce to an external service. Salesforce allows up to 100 callouts per transaction.
If the synchronous Apex trigger sends a single SMS request per record, it can exceed the limit during a bulk update transaction. As soon as the transaction performs the 101st callout, the transaction fails. It depends on how the integration was configured that a previous set of calls reaches the provider even though Salesforce rolled back its data changes. Thus, the SMS provider sends the messages to the first set without any corresponding record in the Salesforce database, or the messages could appear as failed, due to limits or retries, despite being received by the provider.
What Breaks at 50,000 Messages and Where It Fails
Salesforce bulk SMS limits do not all surface at the same moment. Each limit has its own breaking point. The callout ceiling fails at 100 records. The row limit fails when the query is too broad. The DML ceiling fails when the logging layer is too heavy. Same campaign, different failure, depending on which architectural decision is wrong.
API Callouts Fail at the First 100 Records
Every external REST (Representational State Transfer) endpoint used for messaging is one callout. There can be no more than 100 callouts per transaction. If a synchronous trigger sends SMS to one record at a time, it will reach the callouts limit when processing the 101st record and fail. This happens both when there are 500 records on the send list and when there are 50,000 records. Most bulk Salesforce text failures at scale trace back here first — not because the volume is too high but because the architecture was synchronous when it needed to be asynchronous.
SOQL Row Limits Fail at 50,000 Records Fetched in One Go
Salesforce allows a maximum of 50,000 rows returned per transaction across all queries combined. An implementation that fetches the entire target audience — all 50,000 contacts or campaign members — in a single query hits this ceiling before a single message is prepared. The query does not return partial results. The transaction fails completely.
DML Record Limits Break the Logging Layer at 10,000 Records
Every message sent needs a record created to log it — an SMS log object, an activity, a status update. Salesforce allows 10,000 Data Manipulation Language record changes per transaction. A send job attempting to create 50,000 log records in one transaction fails at record 10,001. The messages may have been sent. The evidence that they sent does not exist.
Heap Size Fails at 6MB Synchronous and 12MB Asynchronous
Storing 50,000 phone numbers, message content, and data payload in memory simultaneously consumes more than the allowed heap size limit. The transaction does not pause as memory usage increases but fails when reaching the maximum value, usually before sending any messages in a bulk message send scenario.
CPU Time Runs Out Last but Compounds Everything Above It
Salesforce allows 10 seconds of CPU time per synchronous transaction and 60 seconds asynchronously. When SMS governor limit failures compound across a single execution — callout ceiling hit, row limit breached, memory exhausted — the CPU clock is already running against whatever processing remains. Formatting, serializing, and preparing 50,000 message payloads exhaust that window independently. When CPU time expires mid-execution, partial sends are the result — with no reliable way to determine which records completed before the clock ran out.
Each limit fails independently. In a poorly architected bulk send, they fail consecutively — fix the callout problem, hit the row limit, fix the row limit, hit the DML ceiling. The architecture that handles all five does not address them one at a time. It removes the conditions that make each one the binding constraint.
How to Send 50,000 Messages from Salesforce Without Breaking Limits
Sending 50,000 messages without breaking is possible with a new workflow that is capable of processing every group without transactional limits or forgetting about delivery status. The following adjustments will help maintain the Salesforce bulk SMS limits:
- Process recipients in batches: Use either Batch Apex or Queueable Apex for batch processing of the load in multiple transactions.
- Minimize database operations: Query recipients at once and perform bulk updates of their records.
- Check the SMS provider’s API: Check if your SMS provider’s API allows bulk sending of messages.
- Log results separately: Record provider responses and update SMS logs in batches.
- Make retries safe: Save message IDs and statuses to avoid resending messages the provider has already accepted.
Final Thoughts: Salesforce Bulk SMS Limits Are an Architecture Problem
Salesforce bulk SMS limits at 50,000 messages are not a volume problem that requires a volume solution. Adding more licenses does not increase per-transaction limits either. Upgrading editions raises daily API limits but does not change the 150 DML or 100-callout constraints that cause most bulk messaging failures.
The solution is architectural — moving processing from synchronous to asynchronous, decoupling Salesforce-side logic from external API calls, and building retry logic that handles partial failures without creating duplicate sends. These changes are not complex individually. They require understanding which limit is the binding constraint for a specific implementation before deciding which change to make.
Planning High-Volume Texting from Salesforce?
Talk to our team about a bulk SMS setup that stays inside Salesforce governor limits.
