100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Apex Quick Reference

A fast lookup for Apex collection syntax, SOQL/DML statement forms, and the exact governor limit numbers that matter day-to-day.

PracticeBeginner7 min readJul 10, 2026
Analogies

Apex Quick Reference

This reference condenses the syntax and limits an Apex developer reaches for daily: collection types (List, Set, Map), SOQL/DML statement forms, and the governor limit numbers that determine whether code is safe at scale. It's meant as a fast lookup during code review or debugging, not a tutorial — pair it with the best-practices topic for the reasoning behind each pattern.

🏏

Cricket analogy: A fielding position cheat sheet pinned in the dressing room lets a captain make split-second field changes without recalculating from scratch — this quick reference serves the same fast-lookup purpose for Apex syntax and limits.

Data Types and Collections

The three core collection types are List<T> (ordered, allows duplicates, index-accessed), Set<T> (unordered, unique elements, ideal for collecting distinct Ids before a query), and Map<K,V> (key-value pairs, commonly Map<Id, SObject>, ideal for O(1) lookups keyed by record Id). SObject collections like List<Account> or Map<Id, Contact> are the backbone of bulk-safe Apex, and Salesforce also auto-generates a Map<Id, SObject> constructor directly from a List<SObject>, which is the idiomatic one-line way to convert query results into a lookup structure.

🏏

Cricket analogy: A batting order preserves sequence and allows two players with the same surname, while a squad roster only cares who's included once, and a scorecard indexed by player number gives instant lookup — the three Apex collection types mirror these three cricket record-keeping needs exactly.

apex
// Collections quick reference
List<Account> accts = [SELECT Id, Name FROM Account LIMIT 10];
Set<Id> acctIds = new Set<Id>();
for (Account a : accts) {
    acctIds.add(a.Id);
}
Map<Id, Account> acctsById = new Map<Id, Account>(accts);

// SOQL / DML forms
List<Contact> cons = [SELECT Id, LastName FROM Contact WHERE AccountId IN :acctIds];
insert cons;
update cons;
delete cons;
Database.SaveResult[] results = Database.insert(cons, false); // partial success
upsert cons Contact.External_Id__c;

Governor Limits Cheat Sheet

The limits that matter most day-to-day: 100 synchronous SOQL queries per transaction (200 for asynchronous), 50,000 total records retrieved by SOQL queries, 150 DML statements, 10,000 DML rows processed, 10,000ms CPU time synchronous (60,000ms asynchronous), 6MB heap size synchronous (12MB asynchronous), and 100 SOSL queries. Trigger context specifically caps at 200 records per invocation because Salesforce chunks bulk DML into batches of 200 before invoking triggers, which is exactly why every bulk test should insert or update at least 200 records to genuinely exercise the worst case.

🏏

Cricket analogy: A T20 innings caps at 20 overs no matter how well the batting side is going — Apex's transaction limits (100 SOQL queries, 150 DML statements) cap execution no matter how much work still needs doing.

Check current limit usage at runtime with Limits.getQueries(), Limits.getDMLStatements(), Limits.getCpuTime(), and their corresponding Limits.getLimitQueries() etc. methods — useful for defensive logging in complex batch jobs.

  • Use List for ordered, duplicate-allowing collections; Set for unique elements (ideal for collecting Ids); Map for keyed O(1) lookups, typically Map<Id, SObject>.
  • new Map<Id, SObject>(someList) is the idiomatic one-line conversion from query results to an Id-keyed lookup structure.
  • Core sync limits: 100 SOQL queries, 150 DML statements, 10,000 DML rows, 10,000ms CPU time, 6MB heap size.
  • Async limits are higher: 200 SOQL queries, 60,000ms CPU time, 12MB heap size.
  • Trigger invocations are chunked at 200 records, so bulk tests should always use 200+ records to exercise the worst case.
  • Use Database.insert(list, false) for partial-success DML that doesn't roll back the whole transaction on one bad record.
  • Query Limits.getQueries(), Limits.getDMLStatements(), and Limits.getCpuTime() at runtime for defensive logging in complex jobs.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#ApexSalesforceStudyNotes#ApexQuickReference#Apex#Quick#Reference#Data#StudyNotes#SkillVeris#ExamPrep