Salesforce Governor Limits Explained for Exam Preparation

Why limits exist

Salesforce runs many customers on shared infrastructure. Governor limits protect that shared environment by placing boundaries on work performed in a transaction.

For exam preparation, focus on the design lesson behind each limit: perform work in sets, query only what is needed, avoid repeated processing, and move appropriate work outside the current transaction.

Think in transaction boundaries

A limit normally applies within a defined execution context. Map the start of the transaction, synchronous work, automation that joins it, and any asynchronous boundary. This makes limit questions easier than memorising disconnected numbers.

• Count queries and DML statements across all logic in the transaction.
• Remember that automation can add work beyond the visible Apex method.
• Treat CPU time and heap as signs of algorithm and data-volume pressure.
• Use asynchronous processing for suitable deferred workloads, not as a universal escape.

Bulkification is a design principle

Bulkification means designing one operation to handle collections of records efficiently. Gather identifiers, query related data once, organise it in maps, calculate changes in memory, and perform DML on collections.

This approach improves reliability for imports, integrations, scheduled operations, and user actions that affect multiple records.

Compare asynchronous tools by purpose

Future methods, queueable Apex, batch Apex, and scheduled Apex support different execution and orchestration needs. Compare their input constraints, monitoring, chaining, data volume, and scheduling behaviour before selecting one.

Use a repeatable exam method

When a scenario mentions limits, identify the repeated operation, estimate how its work grows with record count, and choose the option that consolidates or defers work while preserving the required result. Confirm current numeric limits in official Salesforce documentation because platform limits can evolve.