When to Choose Before Event vs After Event in Salesforce Triggers

Posted by Vinay Vernekar 12th November 2025

Understanding Before vs After Triggers in Salesforce Apex

Salesforce triggers run either before or after DML events on sObjects. Choosing between a before and after trigger affects when data is validated, modified, and whether external systems or related records can be accessed. This guide explains practical scenarios to pick the right type, shows concise Apex examples, and lists best practices for reliable, bulkified trigger code.

Key differences (at a glance)

Before trigger: runs prior to saving records to the database — ideal for validation and modifying the record itself. After trigger: runs after the record is committed — ideal for operations that require record IDs, related records, or external interactions.

When to use BEFORE triggers

Use a before trigger when you need to:

  • Modify field values on the same record (e.g., auto-populate fields, set defaults).
  • Perform validation that prevents the DML operation (throw an error to stop save).
  • Avoid extra DML — changes made to Trigger.new are applied without separate update DML.

Before trigger example

// Before insert: set default Stage for Opportunity if not provided
trigger OpportunityBeforeInsert on Opportunity (before insert) {
for (Opportunity opp : Trigger.new) {
if (opp.StageName == null) {
opp.StageName = 'Prospecting';
}
}
}

When to use AFTER triggers

Use an after trigger when you need to:

  • Work with system-generated values like record IDs (ID is available after insert).
  • Query or modify related records that require the parent record to exist.
  • Call future methods, queueable jobs, or send outbound messages/integrations.
  • Perform operations that should run only if the database transaction succeeds.

After trigger example

// After insert: create a related custom child record using the new Opportunity Id
trigger OpportunityAfterInsert on Opportunity (after insert) {
List children = new List();
for (Opportunity opp : Trigger.new) {
children.add(new CustomChild__c(Opportunity__c = opp.Id, Name = 'AutoChild'));
}
if (!children.isEmpty()) insert children;
}

Common decision checklist

Ask the following to decide:

  • Do I need the record Id or other committed changes? — If yes, use after.
  • Am I only changing fields on the same record? — If yes, use before (avoids extra DML).
  • Will I be performing callouts or async processing? — Use after to ensure transaction success, then queue jobs/callouts.

Best practices

  • Keep triggers slim: delegate logic to handler classes (Trigger Handler pattern) for testability and maintainability.
  • Bulkify: always handle Trigger.new as a list, avoid SOQL/DML in loops.
  • Use context checks (Trigger.isInsert, Trigger.isUpdate, Trigger.isBefore, Trigger.isAfter) to group logic.
  • Avoid mixing complex business logic inside triggers; use services and batch/queueable jobs for heavy work.
  • Prefer before trigger to set or adjust fields before save; prefer after trigger for actions reliant on persisted data.

Summary

Use before triggers to validate or set values on the current record before it’s saved, and use after triggers when you need the record to exist in the database (ID available), to interact with related records, or to kick off integrations and async processes. Choosing the right context improves performance, reduces extra DML, and avoids subtle bugs in your Apex trigger logic.

Tags: