Apex Triggers | EXPLAINED | Salesforce Makes Sense

Main ideas / lessons conveyed

What Apex Triggers are (purpose)

Apex triggers let you run custom logic at specific “trigger points” when Salesforce records are:

• Inserted
• Updated
• Deleted
• (For supported objects) Undeleted from the recycle bin

Triggers run either:

• Before Salesforce performs the database operation, or
• After Salesforce completes it

---

Where triggers fit in the automation landscape (vs Flow / Process Builder)

Triggers are useful when you need capabilities that process builder and some flow setups don’t support, especially:

• Before events handling (e.g., validating data or changing values pre-save)

• Better error handling and more user-friendly messages

• Handling delete / undelete events
• Implementing complex logic that would be hard to maintain in flow/process automation
• Allowing partial success behavior (as opposed to the “all-or-none” style failures common in process-based automation)

---

Trigger types / timing

Before triggers

Used primarily for:

• Setting/deriving field values on the same record
• Validations to prevent bad data from being saved

After triggers

Used primarily for:

• Post-processing
• Performing DML on related/unrelated records
• Actions like sending emails, creating tasks, or updating other records

---

Core trigger event model

Triggers can be defined for these events:

• before insert
• before update
• before delete
• after insert
• after update
• after delete
• after undelete (not available for all objects)

Key note:

There is no before undelete because undelete timing can’t be predetermined; attempting it is unsupported.

---

Bulkification requirement (important best practice)

Salesforce triggers are bulk-aware:

• They may receive multiple records in one transaction.
• Your code must handle lists/collections—never assume “single record only.”

---

Methodology / “how to think about triggers” (detailed guidance)

1) Choose the correct operation and timing

Decide:

• Which database event you’re responding to: insert / update / delete / undelete

• Whether you need before or after:

Use before when you need to:

• Modify fields on the record being saved
• Validate data and block save using errors

Use after when you need to:

• Update/insert/delete other records
• Perform post-save actions (emails, tasks, platform events, etc.)

---

2) Write trigger logic using the correct trigger event declaration

In the trigger signature, declare exactly the events you intend to handle.

If you don’t declare an event (example: only before insert is listed), then:

• Code that relies on that undeclared event will not run

---

3) Use trigger context variables to branch logic

Because a single trigger can handle multiple events, branch using Salesforce-provided context variables from the Trigger class.

Common flags mentioned:

• CRUD operation flags
  • Trigger.isInsert
  • Trigger.isUpdate
  • Trigger.isDelete
  • (also mentioned) Trigger.isUndelete
• Timing flags
  • Trigger.isBefore
  • Trigger.isAfter

---

4) Use the correct “records data” variables

• Trigger.new
  • Contains the new values being committed.
• Trigger.old
  • Contains the previous values (before update/delete).
  • On insert, Trigger.old is typically null/empty because there is no prior version.
• Trigger.newMap / Trigger.oldMap
  • Map form keyed by record Id
  • Availability depends on context (example observation: newMap appears for after insert, not for before insert)

---

5) Understand read-only vs modifiable behavior

• Trigger.old is read-only (cannot be updated).
• Trigger.new is modifiable only in before context for the same record.
• In after context:
  • The record being processed is treated as read-only to prevent recursion/loops
  • You can modify other records via separate DML, not the current record instance

---

6) Avoid recursion and “looping updates”

Updating the same record in an after trigger can cause the trigger to fire again, creating recursion/loops.

Salesforce prevents this via enforced read-only behavior in that context.

---

7) Use Trigger.size for bulk logic decisions

• Trigger.size tells you how many records are in the current trigger invocation.
• Use it to branch behavior or avoid limit issues when appropriate.

---

8) Respect Salesforce order of execution

Emphasized high-level order for record updates:

1. UI/page checks and validations occur first (page layouts, referential integrity, custom validation rules for certain scenarios)

2. Before record-triggered flows

3. Before triggers (where before insert/before update logic belongs)
4. Further validation and duplicate rule checks
5. Record is saved to database (not final commit yet)
6. After triggers
7. After record-triggered flows
8. Parent rollups / updates (rollup-like behavior)
9. Sharing and final commit
10. Asynchronous/post-processing actions after commit

---

9) Follow best practices for maintainability

• One trigger per object
  • Avoid multiple trigger files on the same object for the same event because:
    • Execution order across multiple triggers is not guaranteed
    • This can lead to inconsistent behavior and bugs

---

10) Build your own event-vs-context cheat grid

Recommended approach:

• Create a grid showing which variables are available in each event/context combination
• Use debug logs (System.debug) per event/context
• Observe whether values like Trigger.old, Trigger.newMap, etc. are populated or null
• Fill the grid based on what Salesforce provides in practice

---

Speakers / sources featured

• Speaker: Video host/instructor (name not provided in subtitles), delivering: “Apex Triggers | EXPLAINED | Salesforce Makes Sense” and teaching a planned 30-video trigger use-case series.

• Source/system mentioned: Salesforce Platform (Apex Trigger framework, Trigger class context variables, and Salesforce order of execution)