Database Save Process
Learning Content
Last updated: July 21, 2026
Database Save Process
The Database Save Process is the stage in Salesforce where a record is written to the database after successfully passing all earlier validations and pre-save automation. At this point, Salesforce stores the record internally and assigns a unique record Id (for new records), but the transaction has not yet been committed.
This distinction is important because even though the record now exists in the database transaction, Salesforce can still roll back the entire transaction if an error occurs later in the execution flow.
💡 LearnFrenzy Insight
Imagine purchasing a movie ticket online.
After you click Pay, the system temporarily reserves your seat and generates a booking reference, but the booking isn't finalized until the payment is successfully completed.
Similarly, Salesforce writes the record to the database and assigns an Id, but the transaction isn't permanently committed until all remaining processing completes successfully.
Where Does the Database Save Process Execute?
User Clicks Save
│
▼
System Validation
│
▼
Before-Save Flow
│
▼
Before Trigger
│
▼
Validation Rules
│
▼
Duplicate Rules
│
▼
⭐ Database Save Process
│
▼
After Trigger
│
▼
Automation
│
▼
Commit Transaction
Once Duplicate Rules are successfully completed, Salesforce writes the record into the database transaction. The record is now available for subsequent processing, including After Triggers and later automation.
What Happens During the Database Save Process?
| Step | Description |
|---|---|
| 1 | Salesforce prepares the final version of the record after all pre-save processing. |
| 2 | The record is written into the database transaction. |
| 3 | New records receive a unique Salesforce Record Id. |
| 4 | The record becomes available to After Triggers. |
| 5 | The transaction remains open until the final commit. |
Record State During This Stage
| Property | Status |
|---|---|
| Record Written to Database | ✔ Yes |
| Record Id Assigned (Insert) | ✔ Yes |
| Transaction Committed | ❌ No |
| Rollback Still Possible | ✔ Yes |
| Available to After Trigger | ✔ Yes |
| Visible Outside the Transaction | ❌ Not Until Commit |
Real Business Scenario
🏢 Business Example
A sales representative creates a new Opportunity.
After all validations pass:
- Salesforce assigns a new Opportunity Id.
- The Opportunity is written to the database transaction.
- An After Trigger creates related Opportunity Team Members.
- If the After Trigger later throws an exception, Salesforce rolls back the Opportunity and all related records.
Although the Opportunity received an Id, it was never permanently committed because the transaction failed.
Database Save vs Commit Transaction
| Feature | Database Save | Commit Transaction |
|---|---|---|
| Record Written | ✔ Yes | Already Written |
| Record Id Available | ✔ Yes | Yes |
| Rollback Possible | ✔ Yes | ❌ No |
| After Trigger Executes | After Save | Already Completed |
| Changes Permanent | No | Yes |
Common Activities After Database Save
| Automation | Runs After Database Save? |
|---|---|
| After Trigger | ✔ Yes |
| Workflow Rules | ✔ Yes |
| After-Save Flow | ✔ Yes |
| Roll-Up Summary | ✔ Yes |
| Commit Transaction | Occurs Later |
🔍 Behind the Scenes: What Happens Internally?
Validation Complete
│
▼
Duplicate Rules Passed
│
▼
Record Written to Database
│
▼
Salesforce Assigns Record Id
│
▼
Transaction Still Open
│
▼
After Trigger Executes
│
▼
More Automation Runs
│
▼
Commit Happens Later
A common misconception is that the record becomes permanent immediately after it is written to the database. In reality, Salesforce keeps the transaction open so later automation can still succeed or fail as a single unit of work.
Why Is This Important?
| Reason | Explanation |
|---|---|
| Supports Rollback | If any later automation fails, Salesforce can undo all changes. |
| Maintains Data Integrity | Prevents partially completed transactions. |
| Provides Record Id | After Triggers can reference the newly assigned Id. |
| Supports Transaction Consistency | Ensures all automation succeeds or fails together. |
✅ Best Practice
Design your automation with the understanding that a record written to the database is not yet permanent. Handle exceptions carefully, bulkify your logic, and avoid unnecessary failures in later stages that could roll back the entire transaction.
⚠️ Common Mistake
Assuming that once a record has an Id, it is permanently saved. A record can have a valid Salesforce Id and still be rolled back if an exception occurs before the transaction is committed.
🎯 Interview Tip
Question: Can a record have a Salesforce Id and still not exist after the transaction finishes?
Answer: Yes. Salesforce assigns an Id during the Database Save Process, but if a later After Trigger, Flow, or other automation throws an unhandled exception, the entire transaction is rolled back and the record is not permanently stored.
📌 Quick Revision
- ✔ Executes after Duplicate Rules.
- ✔ Writes the record into the database transaction.
- ✔ Assigns a Record Id for new records.
- ✔ Transaction is still open.
- ✔ Rollback is still possible.
- ✔ After Trigger executes next.
- ✔ Permanent save occurs only during Commit Transaction.
➡ Next Lesson
In the next lesson, you'll learn about After Trigger, how it differs from Before Trigger, and why it is the right place for creating related records, calling business services, and performing post-save processing.
Practice What You've Learned
Test your understanding with these practice exercises