Salesforce Governor Limits PDF download

Salesforce Governor Limits PDF Download and Current Apex Governor Limits

This Salesforce developer tutorial explains Salesforce Governor Limits, the most commonly checked Apex limits, the practical limitations developers face, and how to set up Apex governor limit email warnings in Salesforce. If you are new to the platform, first review what Salesforce is, because governor limits are closely connected to Salesforce’s shared, multi-tenant architecture.

Salesforce Governor Limits are runtime limits enforced by the platform so that one transaction, user, integration, or org does not consume excessive shared resources. They apply to Apex code, SOQL, SOSL, DML, callouts, heap memory, CPU time, asynchronous jobs, and other platform operations.

The downloadable PDF link at the end of this page is useful as a quick reference, but always verify exact numbers in Salesforce’s current official documentation before using a limit in production design. Salesforce can update limits by release, edition, license, feature, namespace, or execution context.

What Salesforce Governor Limits Mean in a Multi-Tenant Org

Salesforce runs many customers on shared infrastructure. Governor limits protect that shared environment by restricting how much work a single transaction can do. A transaction can be a trigger execution, Visualforce request, Lightning controller action, Flow interview with Apex, API operation, test method, Queueable job, Future method, or a Batch Apex execution chunk.

When a transaction exceeds a hard governor limit, Salesforce throws a runtime exception such as a SOQL, DML, heap, or CPU limit error. These errors are not normal validation errors; they usually require code, automation, query, or data-volume changes.

System.LimitException: Too many SOQL queries: 101
System.LimitException: Too many DML statements: 151
System.LimitException: Apex CPU time limit exceeded
System.LimitException: Apex heap size too large

Salesforce Governor Limits Cheat Sheet for Apex Transactions

The following table covers the Apex limits most developers check first. Use it as a study and debugging guide, not as a replacement for the official Salesforce governor limits reference.

Governor limit area	Synchronous Apex	Asynchronous Apex	Developer note
Total SOQL queries	100	200	Move queries outside loops and query all required records in bulk.
Total records retrieved by SOQL	50,000	50,000	Use selective filters, indexed fields, pagination, or Batch Apex for large volumes.
Total SOSL queries	20	20	Use SOSL for search-style requirements, not as a replacement for precise SOQL.
Total DML statements	150	150	Combine records into lists and perform one insert, update, delete, or upsert where possible.
Total DML rows	10,000	10,000	For higher volumes, split work with Batch Apex, Bulk API, or carefully designed async processing.
Maximum CPU time	10,000 milliseconds	60,000 milliseconds	CPU time includes Apex processing and many platform operations in the transaction.
Total heap size	6 MB	12 MB	Avoid storing unnecessary records, large strings, debug payloads, or full response bodies in memory.
Callouts in one transaction	100	100	Use asynchronous Apex for long-running integrations and keep timeout handling explicit.
Email invocations	10	10	Build one email list and send messages together instead of sending inside loops.

Some older Salesforce Governor Limits lists mention a “maximum number of script statements.” That limit is no longer the main way Apex execution is controlled. CPU time, heap size, SOQL, DML, and other transaction limits are more useful for modern troubleshooting.

Batch Apex Governor Limits and Large Data Processing

Batch Apex helps when a job must process more records than a single transaction can safely handle. Each execution chunk gets its own governor limit context, so a batch with a scope of 200 records is processed in separate transactions.

• Only one batch Apex job’s start method can run at a time in an organization.
• Up to 5 queued or active batch jobs are allowed for Apex.
• Maximum 2,50,000 batch Apex method executions are allowed per 24-hour period, subject to org limits and license rules.
• The batch Apex start method can have up to 15 query cursors open at a time per user.
• Up to 50 million records can be returned by a Database.QueryLocator object.

For example, if you process 1,000 records with a batch scope of 200 records, Salesforce divides the work into 5 execute transactions. Each execute transaction receives a fresh set of per-transaction Apex governor limits.

Batch Apex is helpful for scheduled cleanups, data fixes, mass updates, integrations, and recalculations. For user-facing work, use it only when delayed processing is acceptable, because Batch Apex is asynchronous.

Common Salesforce Governor Limit Errors and What They Usually Mean

Error message	Likely cause	Typical fix
Too many SOQL queries: 101	A query runs repeatedly inside a loop, trigger recursion, or layered automation.	Bulkify the query, use maps, and review trigger/Flow interactions.
Too many DML statements: 151	Records are inserted, updated, or deleted one at a time.	Collect records in a list and run one DML operation outside the loop.
Too many DML rows: 10001	One transaction attempts to change more than 10,000 rows.	Use Batch Apex, Bulk API, or split processing by record group.
Apex CPU time limit exceeded	Code, automation, recursion, formulas, or large data processing consumes too much server time.	Reduce nested loops, simplify automation, make queries selective, and move heavy work async.
Apex heap size too large	The transaction stores too many records, collections, blobs, strings, or response payloads in memory.	Query only required fields, process records in chunks, and clear large collections when no longer needed.

Salesforce Governor Limits Best Practices for Apex Code

The safest way to overcome governor limits in Salesforce is to design Apex for bulk execution from the beginning. Triggers can receive many records at once from imports, integrations, mass updates, Data Loader operations, and automation.

1. Never place SOQL queries inside loops.
2. Never place DML statements inside loops.
3. Use maps and sets to connect parent and child records efficiently.
4. Query only the fields you need, and always use selective WHERE clauses for large objects.
5. Use Batch Apex when processing more than 50,000 queried records or when work must be split into chunks.
6. Use Queueable Apex or Future methods for callouts and work that does not need to finish in the original transaction.
7. Use Database.getQueryLocator in Batch Apex for very large data sets.
8. Use the IN clause with a Set of IDs instead of running one query per record.
9. Prevent trigger recursion when automation updates the same records again.
10. Use the Limits class in tests and debug logs to understand consumption before production users hit a hard limit.

Apex example that causes a SOQL governor limit error

The following pattern is unsafe because it runs one query for each account in the trigger context.

for (Account acc : Trigger.new) {
    List<Contact> contacts = [
        SELECT Id, Email
        FROM Contact
        WHERE AccountId = :acc.Id
    ];

    // Business logic here
}

Bulkified Apex pattern that stays within SOQL limits

This version collects all Account IDs first, runs one SOQL query, and uses a map for record-by-record logic.

Set<Id> accountIds = new Set<Id>();

for (Account acc : Trigger.new) {
    accountIds.add(acc.Id);
}

Map<Id, List<Contact>> contactsByAccountId = new Map<Id, List<Contact>>();

for (Contact con : [
    SELECT Id, Email, AccountId
    FROM Contact
    WHERE AccountId IN :accountIds
]) {
    if (!contactsByAccountId.containsKey(con.AccountId)) {
        contactsByAccountId.put(con.AccountId, new List<Contact>());
    }

    contactsByAccountId.get(con.AccountId).add(con);
}

for (Account acc : Trigger.new) {
    List<Contact> relatedContacts = contactsByAccountId.get(acc.Id);

    // Business logic here
}

Limitations of Future Methods, Batch Apex, and Sharing Recalculation

Asynchronous Apex increases some limits, but it does not remove governor limits. It also has its own restrictions, so it should be used for the right kind of work instead of being treated as a general workaround.

• Methods declared as future are not allowed in classes that implement the Database.Batchable interface.
• Methods declared as future cannot be called from a Batch Apex class.
• Future methods cannot return a value to the original caller.
• For callouts, use @future(callout=true) or Queueable Apex with callout support.
• For sharing recalculations, the execute method should delete and then recreate the required Apex managed sharing records for the records in the batch.

When you use Apex and Data Loader together, remember that bulk data imports can fire triggers for many records. Code that works for one record in the user interface can fail quickly during an import if it is not bulkified.

Salesforce Describe Limits, Metadata Calls, and Record Setup Checks

Older governor limit notes often mention describe limits for picklists, record types, relationships, and fields. In current Apex design, the better practice is still the same: avoid repeating expensive describe calls in loops, cache metadata results within the transaction, and query only what the code needs.

• Check Salesforce record type logic before assuming every profile or page layout uses the same values.
• Review Salesforce object relationships before writing parent-child queries.
• Use only required Salesforce custom fields in SOQL SELECT clauses.
• When Apex creates or removes sharing rows, review Salesforce sharing rules and sharing model behavior.

How to Set Up Governor Limit Email Warning in Salesforce

Salesforce can send Apex warning emails when a user invokes Apex code that exceeds 50% of selected governor limits. This helps developers and administrators identify risky code paths before users repeatedly hit hard runtime failures.

• Go to Setup | Administer | Manage users | Users | Edit
• Open the user record that should receive warning emails.
• Select Send Apex Warning Emails.
• Save the user record.

To activate the Send Apex Warning Emails checkbox, the user generally needs administrative access to edit the user record. If you cannot see or change this option, ask a Salesforce administrator to review your profile permissions.

How to Monitor Governor Limits While Testing Apex

Before deploying Apex, test with realistic record volumes. Single-record tests may pass even when production imports, integrations, or bulk updates fail. Debug logs, Apex test assertions, and the Limits class help you see how close the code is to Salesforce Governor Limits.

System.debug('SOQL used: ' + Limits.getQueries() + ' of ' + Limits.getLimitQueries());
System.debug('DML used: ' + Limits.getDmlStatements() + ' of ' + Limits.getLimitDmlStatements());
System.debug('CPU used: ' + Limits.getCpuTime() + ' of ' + Limits.getLimitCpuTime());

These checks should not replace proper assertions, but they are useful when diagnosing a limit issue in a test class, sandbox, or debug log.

Download Salesforce Governor Limits PDF

Click here :- Download list of Governor limits in Salesforce PDF file.

After downloading the PDF, compare it with the official Salesforce references for the release you are working on. For current platform details, review the Salesforce Apex Governor Limits reference and the Apex Developer Guide before finalizing any architecture or data migration plan.

• Salesforce App Limits Cheatsheet PDF
• Salesforce Apex Governor Limits reference
• Execution Governors and Limits in the Apex Developer Guide
• Salesforce Apex Developer Guide PDF

Editorial QA Checklist for Salesforce Governor Limits PDF Content

• Confirm that SOQL, SOSL, DML, heap, CPU, callout, and email invocation numbers match the current Salesforce documentation.
• Check whether any limit depends on synchronous Apex, asynchronous Apex, managed package namespace, edition, license, or release.
• Verify that examples do not place SOQL or DML inside loops.
• Confirm that Batch Apex guidance explains scope-based transactions instead of implying that Batch Apex removes limits.
• Make sure the PDF download is presented as a quick reference and not as the only source of truth.

Salesforce Governor Limits PDF FAQs