How Salesforce Executes Your Code
By the end of this lesson, you'll be able to:
- Describe, at a high level, what happens between calling Apex and getting a result back
- Explain what a "transaction" means in Apex
- Connect multitenancy, governor limits, and transactions into one coherent mental model
Prerequisites: "Why Apex Exists" and "Reading Debug Logs"
The request lifecycle, simplified
When something triggers Apex to run — a user clicks a button, a record is saved, a scheduled job fires — Salesforce starts a transaction. Everything that happens inside it (every SOQL query, every DML statement, every line of your code) is tracked as one unit, against one shared pool of governor limits.
User action or event
|
v
+-------------------+
| Transaction start | <- governor limits reset to zero here
+-------------------+
|
v
Your Apex runs
(queries, DML,
calculations...)
|
v
+-------------------+
| Transaction commit | <- all changes saved together, or...
| or rollback | <- ...none of them are, if anything failed
+-------------------+Why "all or nothing" matters
If your Apex updates 50 records and the 40th one fails validation, Salesforce doesn't save the first 39 and skip the rest — by default, the entire transaction rolls back, as if none of it happened. This protects data integrity: you never end up with half-finished work silently sitting in your org.
This is also exactly why governor limits are measured per transaction, not per line of code or per class — Module "Governor Limits and Bulk-Safe Code" builds directly on this idea.
Connecting the dots
You now have the three pieces that explain almost every "why does Apex work this way" question you'll hit in this course:
- Multitenancy — many customers share the same infrastructure.
- Governor limits — the rules that protect that shared infrastructure, reset at the start of each transaction.
- Transactions — the boundary those limits are measured against, and the boundary for "all saved" or "nothing saved."
Every module from here forward assumes you have this mental model.
Exercise
In your own words, explain to a teammate why a transaction that fails halfway through doesn't leave 'half' of its changes saved.
Show hint
Think about what would happen to data integrity if partial saves were allowed — what kinds of bugs could that cause?
How Salesforce Executes Your Code Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Every piece of Apex you run — whether from Execute Anonymous, a trigger, or a button click — executes inside a transaction: a single, all-or-nothing unit of work that Salesforce tracks governor limits against from start to finish.