Apex Triggers Scenarios With Code
A collection of real-world Apex Trigger interview scenarios with full working solutions. Each card below links to a complete walkthrough, including the business requirement and the trigger code that solves it.
On Lead we have a custom lookup field named Company Owner (User), plus a Company (Account) field. On Account we have a custom field called CEO (User). While creating a Lead, if the linked Company has a CEO, populate that in Company Owner.
View SolutionWhen an Opportunity gets updated, create a new Task on the Primary Contact of that Opportunity.
View SolutionWrite trigger logic such that if Account Rating changes from Hot to anything else, delete all upcoming Tasks associated with that Account.
View SolutionWrite trigger logic to prevent an Account from being deleted if it has Opportunities associated with it.
View SolutionWe have two custom objects, Meeting and Guest. Meeting has a Status field (Scheduled, In-Progress, Completed), and Guest has a Meeting lookup. Write logic so that if Meeting Status is Completed, a Guest cannot be linked to that Meeting.
View SolutionWrite a trigger on Contact to prevent inserting or updating duplicate Contacts, using the Email field to compare against existing Contact records.
View SolutionWhile inserting a Contact, check if the linked Account is already associated with another Contact. Throw an error if yes.
View SolutionApex trigger best practices
The scenarios above are common interview questions. When you answer them, or write triggers in a real project, follow these rules.
- One trigger per object. Salesforce does not guarantee the order of several triggers on the same object, so keep a single trigger and let it call a handler class.
- Keep the trigger logic-free. The trigger should only check the context (
Trigger.isBefore,Trigger.isInsertand so on) and call methods in a handler class. Handler classes are easier to test and reuse. - Bulkify everything. A trigger can receive up to 200 records at once. Never run a SOQL query or DML statement inside a for loop. Collect Ids first, query once, and use a
Mapto look up the results. - Use the right event. Use before triggers to validate or change fields on the same record without extra DML, and after triggers when you need the record Id or want to change related records.
- Avoid recursion. If a trigger updates records that fire the same trigger again, use a static Boolean or a set of processed Ids to stop it from running twice.
- Do not hard-code Ids. Query them or use custom metadata and custom labels.
- Write tests. Cover single record, bulk (200 records), positive and negative cases, and assert the results. Salesforce needs 75% code coverage to deploy to production.
Trigger context variables
Trigger.new: the new versions of the records (insert, update, undelete).Trigger.old: the old versions of the records (update, delete).Trigger.newMapandTrigger.oldMap: maps of Id to record, useful for comparing old and new values.Trigger.isBefore,Trigger.isAfter,Trigger.isInsert,Trigger.isUpdate,Trigger.isDelete: tell you which event is running.
A simple handler pattern
trigger AccountTrigger on Account (before insert, before update) {
if (Trigger.isBefore) {
AccountTriggerHandler.handleBefore(Trigger.new, Trigger.oldMap);
}
}
public with sharing class AccountTriggerHandler {
public static void handleBefore(List<Account> newList, Map<Id, Account> oldMap) {
for (Account acc : newList) {
if (String.isBlank(acc.Description)) {
acc.Description = 'Created by trigger handler';
}
}
}
}When you practice a scenario, write the handler class and the test class as well, not only the trigger. Interviewers often ask how you would structure the code for a real project.