Governor Limits

💬 In plain words: Governor limits are like the referee in a shared stadium. Every time you run a transaction, Salesforce gives you a strict budget: a set number of database queries, DML statements, CPU time, and memory. This ensures no single tenant can hog the servers and crash the platform. You cannot fight limits; you must design for them by bulkifying your code, caching data, and moving heavy lifting to asynchronous processes. 📌 Example: The Scaling Problem Imagine a simple "Sync All Contacts" button. It worked perfectly for small boutique clients with a few hundred contacts. But when a bank with 80,000 contacts clicked it, the system threw an error: Too many query rows: 50001 . Governor limits didn't fail the developer—they acted as an alarm, signaling that this massive workload belongs in Batch Apex, not a real-time button click. 🎬 Real-Life Example: The Loop That Cost 101 Queries You write a trigger to enrich a Del...

💬 In plain words: A flow that runs smoothly on a single record can instantly fail during a 200-record batch update. True bulkification means keeping all queries and DML elements outside of loops, while recursion guards stop flows from triggering themselves repeatedly. Always validate flows with bulk datasets rather than single-record tests. 📌 Example: A flow functions without issues during single-record manual testing. However, a bulk upload of 5,000 leads causes an unhandled exception because a Get Records element was placed inside a loop, triggering 5,000 separate queries. Moving that query prior to the loop and leveraging collection variables keeps the flow entirely bulk-safe. 🎬 Real-Life Scenario: The Flow That Failed at Record 201 A record-triggered flow flags delayed deliveries and generates an alert task for each record. A partner initiates a bulk upload of 5,000 delivery records. The Anti-Pattern: The flow executes a loop contai...

In plain words: Apex errors occur when your code encounters an unexpected situation—like reading an unassigned variable (Null Pointer), requesting a record that does not exist (Query Exception), violating validation rules (DML Exception), or hitting multi-tenant resource caps (Governor Limits). Salesforce Apex executes in a strongly typed, multi-tenant cloud runtime. While this architecture guarantees system security and shared resource availability, it also enforces strict execution rules. Encountering exceptions is part of everyday development, but understanding why they happen and how to resolve them defensively makes your code resilient, scalable, and production-ready.

In plain words: Avoiding errors in Salesforce comes down to writing bulkified code that respects Governor Limits, testing with realistic data volumes, logging failures systematically, and enforcing strict data security rules across your org. Salesforce is a multi-tenant cloud platform, meaning every transaction shares memory, CPU time, and database resources with other processes. When custom automation, Apex triggers, or integrations aren't built defensively, teams run into unhandled exceptions, locking issues, and broken user workflows. Following disciplined architecture principles keeps your org healthy and error-free.

In plain words: Governor Limits are Salesforce's traffic rules for multi-tenant architecture. Because many companies share the same underlying cloud infrastructure, Salesforce enforces strict transaction caps (like memory, queries, and CPU time) so one piece of inefficient code cannot slow down or crash the shared platform. Salesforce executes Apex code in a multi-tenant cloud environment. To guarantee high performance, platform stability, and fair resource sharing, the runtime engine enforces strict per-transaction limits known as Governor Limits . When code exceeds these boundaries, Salesforce throws a fatal runtime LimitException that immediately halts execution. Writing resilient Apex requires a clear understanding of these boundaries and defensive design patterns.

In plain words: Query Exceptions in Salesforce Apex occur when database queries encounter syntax errors, runtime mismatches (such as expecting a single record when zero or multiple return), or breach multitenant governor limits like query counts and row limits. Handling these exceptions gracefully and designing selective, bulkified SOQL queries prevents unexpected transaction rollbacks and improves application stability. Querying the database using SOQL (Salesforce Object Query Language) is a fundamental part of Apex development. However, queries can fail at runtime due to malformed syntax, unhandled cardinality mismatches, or governor limit violations. Understanding these exceptions and applying defensive coding patterns ensures your application runs reliably under heavy enterprise workloads.

In plain words: Data Table Pagination divides massive Salesforce datasets into bite-sized, sequential pages (e.g., 10 or 25 records per view). Instead of pulling thousands of records into the browser at once—which slows down the page and triggers the 170 KB Visualforce view state limit—pagination fetches only the current page's records on demand using server-side Apex queries or the StandardSetController . Displaying large datasets in Salesforce without pagination degrades page responsiveness and risks hitting platform limits. Querying thousands of records at once blows past the 50,000 SOQL row retrieval limit, inflates Visualforce View State beyond 170 KB, and creates a frustrating user experience. Implementing structured pagination in Apex and Visualforce gives users fast, predictable navigation while keeping platform resource consumption minimal.

Salesforce interviews today test more than syntax. Hiring managers want to know that you can protect data, design for scale, and explain why you made each choice. This post covers the questions that come up most often, in two parts: the security model, which every admin and developer must know, and the core developer topics, like governor limits, SOQL, and deployments. In plain words: Salesforce security has two halves. Object-level security (Profiles and Permission Sets) decides whether a user can see or edit a whole type of data, like "Accounts." Record-level security (OWD, Role Hierarchy, and Sharing Rules) decides which specific records, like "Acme Corp" vs. "Stark Industries," that user can see. On the developer side, interviewers look for code that is bulkified, stays inside governor limits, respects security, and is deployed through a proper pipeline.

In plain words: Batch Apex with HTTP Callouts allows Salesforce to sync thousands of records with external systems (such as ERPs, payment gateways, or external databases) in manageable chunks. By adding the marker interface Database.AllowsCallouts to your batch class and capping your batch execution size to 100 records or fewer, you can make external REST/SOAP requests across millions of records without hitting governor limits. Synchronous transactions in Salesforce enforce strict timeout and callout limits, making it impossible to synchronize large datasets directly from UI controllers or record-triggered flows. When enterprise systems require bulk synchronization, scheduled data enrichment, or high-volume status verification, Batch Apex provides the scalable, asynchronous backbone needed to process records in controlled chunks over time.

Encountering governor limit errors in Salesforce is common, but one specific error often catches developers off guard: System.LimitException: Too many DML statements: 1 . This exception does not mean you have exceeded the standard 150 DML statement limit—it means you have attempted to execute even a single insert, update, or delete operation inside a strictly read-only execution context. In plain words: When a Visualforce page is configured with readOnly="true" (or an Apex method is marked with @ReadOnly ), Salesforce sets the maximum allowed DML statements to 0 . Any attempt to modify data triggers Too many DML statements: 1 immediately.