Salesforce Developer cheat sheet

Multi-tenant architecture: all customer orgs share the same application servers and database infrastructure, so per-transaction governor limits rather than dedicated hardware enforce fair resource use.

Core synchronous limits: 100 SOQL queries, 50,000 SOQL rows, 150 DML statements, 10,000 ms CPU time, 6 MB heap; asynchronous Apex raises these to 200 SOQL queries, 60,000 ms CPU, and 12 MB heap.

Callout limits: 100 HTTP callouts per transaction and 120 seconds cumulative callout time; callouts cannot be made after a DML commit in the same transaction without a future or queueable boundary.

Record IDs are 15 characters (case-sensitive) or 18 characters (case-insensitive, with a 3-character checksum suffix); the 3-character prefix identifies the object, e.g. 001 for Account, 003 for Contact.

Access control layers, in order of evaluation: object permissions, then org-wide defaults, then role hierarchy and sharing rules, then manual sharing, then field-level security.

A user has exactly one profile and any number of permission sets; permission sets only add access and can never remove access granted by the profile or another set.

Sandbox types: Developer (small data, 200 MB), Developer Pro (1 GB), Partial Copy (sampled data via template), Full Copy (all data, refresh interval 29 days).

Salesforce APIs by use case: REST and SOAP for record CRUD, Bulk API 2.0 for large data volumes, Metadata API for configuration deployment, Streaming/Platform Events for push notifications.

MVC mapping in Salesforce: sObject and metadata = model, Visualforce or Lightning page = view, Apex controller or LWC controller = controller/logic.

Master-detail: child requires a parent, deleting the parent cascades to children, child inherits the parent's ownership and sharing, and the parent can have roll-up summary fields. Maximum two master-detail relationships per object.

Lookup: parent optional by default, no cascade delete unless 'Don't allow deletion of the lookup record that's part of a lookup relationship' is set, and no roll-up summary fields on the parent.

Many-to-many is modeled with a junction object carrying two master-detail relationships; standard objects such as AccountContactRelation do the same with a different implementation.

Roll-up summary functions are COUNT, SUM, MIN, and MAX only; they can filter child rows by criteria but cannot aggregate formula-derived text or use COUNT_DISTINCT.

An object supports up to 25 external ID fields; upsert with Data Loader or the API matches on an external ID or on Id to update existing records and insert new ones.

SOQL relationship syntax: child-to-parent uses dot notation (SELECT Id, Account.Name FROM Contact); parent-to-child uses a subquery on the child relationship name (SELECT Id, (SELECT Id FROM Contacts) FROM Account).

Formula fields are calculated at read time and are not stored, so they cannot be queried in a WHERE clause with wildcard leading values efficiently and cannot be the target of a roll-up summary.

Data Loader supports insert, update, upsert, delete, and hard delete (hard delete requires the Bulk API permission); default batch size is 200 records and batch size affects governor and lock behavior.

Save order of execution: load record, run before triggers, run system validation, save record (not committed), run after triggers, run assignment rules, auto-response rules, workflow rules, processes and record-triggered flows, escalation rules, roll-up summary recalculation, criteria-based sharing, commit, then post-commit email and async work.

Trigger events: before insert, before update, before delete, after insert, after update, after delete, after undelete. Trigger.new is unavailable in after delete; Trigger.old is unavailable in after insert.

Bulkification rule: never place SOQL or DML inside a loop over Trigger.new; collect IDs into a Set, run one query, and perform one DML call on a collection.

Only one trigger per object should exist, delegating to a handler class so that logic order stays deterministic and recursion can be controlled with a static Boolean guard.

@future methods must be static, return void, and accept only primitives, collections of primitives, or collections of sObjects; the limit is 50 future calls per transaction.

Queueable Apex accepts non-primitive parameters including custom types, returns a job ID for monitoring, and can chain a child job from execute(); Batch Apex uses start, execute, and finish with a default batch size of 200 and up to 5 concurrent jobs.

Flow types: Screen Flow (user interaction), Record-Triggered Flow (before/after save), Autolaunched Flow (called by Apex, processes, or REST), Schedule-Triggered Flow, and Platform Event-Triggered Flow.

Formula syntax differs by tool: Apex uses &&, ||, and !; Salesforce formula fields and Flow formulas use AND(), OR(), and NOT() with single quotes for strings.

Workflow rules can do only field updates, email alerts, tasks, and outbound messages; they cannot create records, and they are evaluated before processes and flows in the save order.

A Lightning Web Component bundle needs a .js file, an .html template, an optional .css file, and a .js-meta.xml configuration file defining the targets and API version.

@api exposes a public property or method to the parent component; @wire binds a property or function to an Apex method (which must be @AuraEnabled(cacheable=true)) or to a Lightning Data Service adapter.

Apex methods called from LWC must be static and annotated @AuraEnabled; cacheable=true is required for wired methods and forbids DML in that method.

Common record base components: lightning-record-form for automatic create/view/edit with layout and FLS handling, lightning-record-edit-form for custom layouts, and lightning-record-view-form for read-only custom display.

Navigation from LWC uses NavigationMixin from lightning/navigation to generate a PageReference, then calls thisNavigationMixin.Navigate to move to a record, list view, or app page.

Component visibility in Lightning App Builder is driven by filter rules on fields or by Dynamic Forms for record pages; user permission-based visibility uses the same filter mechanism.

Visualforce follows classic MVC: apex:page with standardController for single-record CRUD or a custom controller/extension class; it can be embedded in Lightning pages via Visualforce components only where supported.

Deployment to production requires at least 75% Apex code coverage org-wide, with every trigger covered by at least one test; coverage is calculated on lines of code excluding comments and test classes.

Test.startTest() and Test.stopTest() bracket the code under test so it runs with a fresh set of governor limits; Test.stopTest() also forces @future, queueable, and batch jobs to execute before assertions.

@testSetup methods run once per test class before any test method, and the records they create are available to all tests then rolled back after the class completes.

Test code runs with seeAllData=false by default, meaning it sees only records created within the test transaction; SeeAllData=true should be avoided because it couples tests to org data.

Callouts in tests require Test.setMock(HttpCalloutMock.class, mockInstance) plus an implementation of respond() returning a fabricated HttpResponse; real callouts are blocked in tests.

Asynchronous and callout tests must run inside Test.startTest()/Test.stopTest() so that limits reset and async work completes before assertions.

Assertions use System.assertEquals(), System.assertNotEquals(), System.assert(), and System.isTrue(); a test method with no assertion is not counted as meaningful coverage of behavior.

Debug log levels in ascending verbosity: NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST; each log category (Apex Code, Database, Workflow, Callout, etc.) is set independently in a trace flag.

Debug logs are capped at 20 MB per log, and a single transaction produces one log; System.debug() statements are dropped when the Apex Code level is set to NONE.

Developer Console offers Execute Anonymous, checkpoints for inspecting heap state while replaying a log, and a query editor; Lightning-compatible alternative is the VS Code Apex Replay Debugger.

Outbound change sets move metadata between related orgs (usually sandbox to production) and cannot delete components in the target org or include components with unmet dependencies.

Deployment options: change sets, Metadata API, Salesforce CLI (sf project deploy start), unlocked and second-generation managed packages, and DevOps Center; validation-only deployments run tests without committing changes.

Common deployment failures: coverage below 75%, missing referenced components, API version mismatch, running user lacking permission on components, and test failures caused by hard-coded IDs or data assumptions.

Workbench provides REST Explorer, SOQL queries, metadata describe, and session-based deployment tools; it runs as the logged-in user and respects that user's permissions.

The Salesforce CLI (sf) commands used most in development: sf org login web, sf project retrieve start, sf project deploy start, sf apex run test, and sf apex run for anonymous Apex.