Apex
Trigger design and recursion
Before versus after, change detection, and avoiding brittle recursion guards.
By Vishal Verma · Reviewed October 5, 2026
Practice these questions aloud. Give the principle, explain a concrete example, and finish with how you would verify the result.
1. When should you use a before trigger?
Suggested answer: Use it to validate or set fields on the records being saved. An after trigger is useful when you need saved record IDs or operations on related records. Choose the event based on the required behavior.
Scenario / follow-up: Do not add extra DML just to update a field on Trigger.new in a before trigger.
2. How do you prevent repeated processing?
Suggested answer: Compare old and new values and run only for meaningful transitions. Prefer idempotent logic. If a transaction guard is needed, track the relevant records and operation rather than blindly skipping all later executions.
Scenario / follow-up: A single static Boolean can incorrectly skip records in subsequent trigger chunks.
3. Why use a trigger handler?
Suggested answer: Separate event dispatch from business logic so behavior is easier to review and test. Keep entry points clear and coordinate with Flow and other automation on the object.
Scenario / follow-up: Explain ownership and ordering when several features act on the same record.
Reviewed October 5, 2026. Check the linked documentation for your org’s API version and supported features.