Medium & Hard Apex Trigger Practice Problems

Problem Statement

After inserting or deleting a Contact, update a custom field Contact_Count__c on the parent Account.

The field must always reflect the actual count of contacts linked to that account.

Constraints

• Must handle bulk (up to 200 contacts at once)
• Only one SOQL query and one DML statement total
• Handle contacts without an AccountId gracefully

Problem Statement

Prevent a trigger from running more than once per transaction by implementing a static boolean guard in a handler class.

This is critical when your trigger performs DML that could re-fire the same trigger, causing infinite recursion and hitting the governor limit on recursive trigger depth (16).

Requirements

• Create a TriggerHelper class with a static boolean
• The trigger must check and set the guard on entry
• Write a test proving the trigger runs exactly once even when the DML re-fires it

Problem Statement

Write a before insert trigger on Contact that prevents inserting a contact whose Email already exists on another contact record.

Requirements

• Collect all incoming emails in a Set
• Run one SOQL query to find existing contacts
• Call addError() on the Email field for duplicates
• Skip contacts with no email gracefully

Problem Statement

Write an after update trigger on Opportunity. When an Opportunity's StageName changes to Closed Won, recalculate the parent Account.AnnualRevenue as the sum of all Closed Won opportunity amounts for that account.

Requirements

• Use Trigger.old to detect the stage change
• One aggregate SOQL query with SUM(Amount) and GROUP BY AccountId
• One DML update on the affected accounts

Problem Statement

Write a before insert trigger on Contact that prevents duplicate contacts with the same Email. If a duplicate is detected, add an error on the Email field.

Constraints

• Must be bulkified — collect all emails, query once
• Use addError() on the specific field
• Ignore contacts with a blank/null email

Problem Statement

Write an after insert trigger on Task. When a Task with Subject = 'Close Opportunity' is inserted, set the linked Opportunity's StageName to "Closed Lost".

Use WhatId to find the Opportunity Id.

Constraints

• Only process Tasks where Subject = 'Close Opportunity'
• Bulkified: one SOQL query, one DML update

Problem Statement

Write an after insert, after update, after delete trigger on Case that keeps a custom field Open_Cases__c on Account updated with the count of open (non-Closed) Cases for that account.

Constraints

• Bulkified — collect Account IDs, one aggregate SOQL, one update
• Status != 'Closed' for open cases

Problem Statement

Write a before insert, before update trigger on Contact that enforces a custom rule: if MailingCountry = 'US', the MailingState must not be blank.

Add a field error on MailingState if the rule is violated.

Problem Statement

Write an after update trigger on Account that propagates the Account's Phone to all child Contacts' Phone field whenever the Account's Phone changes.

Constraints

• Only process Accounts where Phone has changed (Trigger.oldMap)
• Bulkified — collect IDs, query once, one update DML

Problem Statement

Write a before update trigger on Opportunity that automatically sets CloseDate to today when the StageName changes to "Closed Won".

Use Trigger.oldMap to compare the old and new values — only update records where the stage actually changed to avoid unnecessary writes.

Key Concept — Trigger.oldMap

Trigger.oldMap is a Map<Id, Opportunity> containing the previous field values before the save. Access it with Trigger.oldMap.get(opp.Id) to compare old vs new.

Constraints

• Trigger event: before update only
• Must use Trigger.oldMap to detect the stage change
• Only set CloseDate when stage transitions to Closed Won (not when it was already Closed Won)
• Handle bulk (up to 200 records) — no SOQL inside the loop

Example

Old StageName: Prospecting  →  New StageName: Closed Won  →  CloseDate = today ✓
Old StageName: Closed Won   →  New StageName: Closed Won  →  No change (already won)
Old StageName: Negotiation  →  New StageName: Needs Analysis → No change

Problem Statement

Write a before delete trigger on Account that prevents deleting any Account that has related Contact records.

Call addError() on the record to surface a user-friendly message and block the deletion.

Key Concept — Before Delete Trigger

In a before delete trigger:

• Trigger.old contains the records about to be deleted
• Trigger.new is always empty — use Trigger.old
• Calling record.addError('message') blocks the deletion
• Trigger.oldMap is a Map<Id, Account> for fast lookup

Constraints

• Collect all Account IDs first, then run one SOQL query (no SOQL in loop)
• Handle bulk: up to 200 accounts being deleted at once
• Gracefully skip accounts that have no contacts

Problem Statement

Write an after undelete trigger on Opportunity that reactivates opportunities when they are restored from the Recycle Bin.

For each undeleted opportunity with a StageName of "Closed Won" or "Closed Lost", reset it to active status:

• Set StageName to "Prospecting"
• Set CloseDate to today + 30 days

Key Concept — After Undelete Trigger

after undelete is the only valid undelete event. In this context:

• Trigger.new contains the restored records (with their Ids)
• Trigger.old is null / empty — there is no "before" state for undelete
• Trigger.isUndelete is true
• After triggers must use DML to persist field changes (you cannot assign fields directly)

Constraints

• Trigger event: after undelete only
• Only modify opportunities that were Closed Won or Closed Lost
• Use a single DML update — collect into a list first
• Handle bulk: up to 200 records

Problem Statement

Write a before update trigger on Account that prevents an account from being deactivated (i.e. IsActive__c set to false) if any linked Opportunity has a StageName that is not Closed Won or Closed Lost.

If the condition is violated, throw a field error on IsActive__c using addError().

Best Practices

• Separate trigger logic into a handler class (AccountTriggerHandler).
• Use a single SOQL query — no SOQL inside loops.
• Bulkify: handle up to 200 records in one trigger invocation.
• Test class must cover positive, negative, and bulk scenarios.

Objects / Fields

• Account — IsActive__c (Checkbox custom field)
• Opportunity — AccountId, StageName

Problem Statement

Write a before update trigger on the custom object Employee__c that blocks changing the Status__c field to "Terminated" if there are no Employee_Review__c records linked to that employee.

Throw a field error on Status__c via addError().

Best Practices

• Handler class pattern — keep trigger thin.
• Bulkify: one SOQL for all employees being terminated.
• Test: positive (has review → allowed), negative (no review → error), bulk.

Objects / Fields

• Employee__c — Status__c (picklist: Active, On Leave, Terminated)
• Employee_Review__c — Employee__c (Lookup to Employee__c)

Problem Statement

All three objects — Account, Contact, and User — have a custom checkbox IsActive__c.

When Account.IsActive__c is unchecked (false):

• Set IsActive__c = false on all related Contacts of that account.
• Set IsActive__c = false on the User linked via Account.OwnerId (only if that user's IsActive__c is currently true).

Best Practices

• Use after update trigger so updates to related records don't affect the in-flight Account.
• Single SOQL per object — no SOQL inside loops.
• Bulkify: multiple accounts can be deactivated at once.
• Test: deactivate account → assert contacts and owner user also deactivated.

Problem Statement

Create a custom object Country_Account_Count__c with fields Country__c (Text) and Account_Count__c (Number).

Write an after insert / after update / after delete / after undelete trigger on Account that keeps this summary object up to date with the total number of accounts per BillingCountry.

Best Practices

• Use a single SOQL aggregate query to recount after any change.
• Upsert (not insert) the summary records using an external Id or existing Ids.
• Handle blank BillingCountry gracefully — skip or group as "Unknown".

Problem Statement

Create a custom field No_of_Total_Contact__c (Number) on the Account object.

Write an after insert / after delete trigger on Contact that updates No_of_Total_Contact__c on the parent account to always reflect the live count of associated contacts.

Best Practices

• Collect all affected Account Ids first.
• One aggregate SOQL query grouped by Account to get each Account's live Contact count in a single round-trip.
• One DML: update all Account records in a single list.
• Test: insert 5 contacts → count = 5; delete 2 → count = 3.

Problem Statement

An Account has 10 linked Opportunities. There is a custom field Contact_Email__c (Email) on Opportunity.

When a user updates Contact_Email__c on any one of those opportunities, automatically propagate that value to all other sibling opportunities linked to the same account.

Best Practices

• Use after update — sibling updates must happen after the original is committed.
• Only propagate when Contact_Email__c actually changed.
• Exclude the triggering opportunity itself to avoid a circular update.
• One SOQL, one DML — no queries inside loops.

Problem Statement

When a Salesforce User is deactivated (IsActive set to false), automatically reassign all of that user's Accounts and Opportunities to the deactivated user's Manager (User.ManagerId).

Best Practices

• Use before update — changing OwnerId on User is only possible via System.runAs() or mixed DML workaround in tests.
• Use @future method to update Account and Opportunity records (mixed DML — you cannot update User and related non-setup objects in the same transaction).
• One SOQL per object, one DML per object.
• Skip users with no ManagerId.

Problem Statement

Your revenue operations team needs to know exactly when each opportunity was first won. When an Opportunity's StageName is changed to 'Closed Won', automatically stamp the current date into a custom field Closed_Won_Date__c (Date).

Requirements

• Use a before update trigger so the field is set before the record is saved.
• Only set Closed_Won_Date__c when StageName changes to 'Closed Won' (not if it was already 'Closed Won').
• Handle bulk updates — no SOQL or DML inside the trigger body.
• Delegate logic to a handler class OpportunityTriggerHandler.

Best Practices

• One trigger per object — delegate everything to a handler class.
• Use Trigger.oldMap to detect field changes.
• In tests, use Test.startTest() / Test.stopTest() to isolate the trigger context.

Problem Statement

Your reporting team needs a real-time count of contacts per account stored in a custom field Contact_Count__c (Number) on the Account object.

Write a trigger ContactTrigger on the Contact object that keeps Account.Contact_Count__c accurate after inserts and deletes.

Requirements

• Fire on after insert and after delete
• Use a single aggregate SOQL query, grouped by Account, to get each affected Account's live Contact count
• Update Account.Contact_Count__c for all affected accounts in one DML
• Delegate logic to ContactTriggerHandler

Best Practices

• Collect all affected AccountIds before the query — no SOQL inside loops.
• Read the per-Account count off the AggregateResult and cast it to Integer.
• Test both insert and delete paths to verify the count increments and decrements.

Problem Statement

Your support team requires that whenever a High priority case is created, a follow-up Task is automatically generated for the case owner reminding them to respond within 2 hours.

Write a trigger CaseTrigger on the Case object and a handler class CaseTriggerHandler that, on after insert:

• Identifies all newly inserted cases where Priority = 'High'
• Creates one Task per high-priority case with:
  • Subject = 'Follow-up: ' + case.CaseNumber
  • WhatId = case Id (links Task to the Case)
  • OwnerId = case OwnerId
  • ActivityDate = Date.today()
  • Priority = 'High'
  • Status = 'Not Started'
• Inserts all tasks in a single bulk DML

Best Practices

• Use after insert — Task.WhatId requires the Case to already have an Id.
• Filter for Priority = 'High' before creating tasks — do not create tasks for Normal/Low cases.
• Collect all Task records first, then insert once — never DML inside a loop.
• Test that Normal priority cases do NOT generate tasks.

Problem Statement

Write a before insert / before update trigger on Lead with handler LeadTriggerHandler that computes Lead_Score__c:

Scores are cumulative. Web + VP + Company + Email = 35 points.

Best Practices

• Reset score to 0 each iteration — idempotent on update.
• Use String.isNotBlank() for null-safe string checks.
• Use containsIgnoreCase() for Title matching.

Problem Statement

Once an Opportunity reaches Closed Won or Closed Lost, it must never be moved back to an open stage.

Write a before update trigger that delegates to OpportunityTriggerHandler.preventStageRegression() and calls addError('Cannot reopen a closed Opportunity.') when violated.

Best Practices

• Define a Set<String> CLOSED_STAGES constant.
• Use Trigger.oldMap to read the previous StageName.
• Only call addError when StageName actually changed to an open stage from a closed one.

Problem Statement

Write a before insert / before update trigger on Contact that prevents two contacts from sharing the same Email.

If a duplicate is found, call Email.addError('A Contact with this email already exists.')

Logic

1. Collect non-blank emails from Trigger.new.
2. Run one SOQL: existing contacts with matching email, excluding records being updated (Id NOT IN :Trigger.newMap.keySet()).
3. Build a Set<String> of existing emails (lowercased).
4. Loop and call addError() on duplicates.

Best Practices

• One SOQL total — never inside a loop.
• Case-insensitive: use .toLowerCase().
• Self-update safe: exclude the record being updated from SOQL.

Problem Statement

When an Opportunity moves to Closed Won, increment its linked Campaign.Won_Opportunities__c (Number) by 1.

Write OpportunityTrigger (after update) and OpportunityTriggerHandler.

Logic

1. Find opps where StageName changed to 'Closed Won' and CampaignId != null.
2. Collect unique CampaignIds.
3. Query the affected Campaigns once, by their Ids, to read each one's current counter.
4. Increment each campaign's counter and update in one DML.

Best Practices

• One SOQL, one DML — never inside loops.
• Compare old vs new StageName to avoid double-counting.
• Initialise Won_Opportunities__c to 0 if null before incrementing.

Problem Statement

Write a before update trigger on Case with handler CaseTriggerHandler. When a Case's Status is set to 'Escalated':

• Set Priority to 'High'.
• Set Escalation_Reason__c to 'SLA Breach — auto-escalated'.
• If the case was already 'Escalated' → addError('Case is already escalated.').

Best Practices

• Use Trigger.oldMap to compare old Status.
• No SOQL — all data in Trigger.new / oldMap.
• Test: valid escalation, double escalation, non-escalated change, bulk 50.

Problem Statement

Write a before insert / before update trigger on Case with handler CaseTriggerHandler that assigns the OwnerId to the matching support queue based on a custom Region__c field.

Logic

1. Collect unique Region__c values from Trigger.new.
2. Query the Group object for queue records whose name matches one of the collected regions.
3. Build a Map<String, Id> of region name → queue Id.
4. Loop Trigger.new and set c.OwnerId when a match exists.

Best Practices

• One SOQL for queues — never inside the loop.
• Guard with regions.isEmpty() before the SOQL.
• Trigger delegates entirely to handler — zero business logic in the trigger file.
• Test covers null Region__c (graceful degradation) and the update path.

Problem Statement

Write a before delete trigger on Account that prevents deletion when there are open (non-closed) Opportunities linked to the Account.

Logic

1. Collect all Account Ids from Trigger.old.
2. Query for open (non-closed) Opportunities linked to those Accounts in a single SOQL call.
3. Build a Map<Id, List<Opportunity>> grouped by AccountId.
4. Call acc.addError('Cannot delete Account: N open Opportunity(ies)...') for each match.

Best Practices

• One SOQL — never inside a loop.
• Message includes the count of blocking records for user clarity.
• Test covers 3 scenarios: blocked (open opp), allowed (no opp), allowed (closed opp only).

Problem Statement

Write OpportunityRevenueRollupTrigger (after insert/update/delete) and OpportunityRevenueRollupHandler that maintains Total_Closed_Won_Revenue__c on Account — the sum of Amount for all Closed Won Opportunities.

Logic

1. Trigger collects affected Account Ids (from Trigger.new AND Trigger.old for updates, Trigger.old for deletes).
2. Handler uses one AggregateResult SOQL with SUM(Amount) GROUP BY AccountId.
3. Builds Map of AccountId → total revenue, queries Accounts, updates only changed records.

Best Practices

• After update: include both old and new AccountIds — the opp may have been moved to a different account.
• Use AggregateResult — never sum in a loop.
• Skip records where the value has not changed.
• Test covers: insert (revenue increases), delete (revenue decreases), open opp (not counted).

Problem Statement

Write a before insert / before update trigger on Opportunity that automatically sets Probability based on StageName.

Stage → Probability Mapping

Best Practices

• Store the mapping as a final Map<String, Integer> constant.
• On updates: skip records where StageName has not changed to avoid overwriting manual overrides.
• Use Trigger.oldMap to detect stage transitions.
• Check containsKey() before calling get().
• No SOQL or DML needed — pure field assignment.

Problem Statement

Write a before insert / before update trigger on Lead with handler LeadDuplicateEmailHandler that prevents two unconverted Leads from sharing the same email address.

Logic

1. Skip blank emails and unchanged emails on update.
2. Query existing unconverted Leads with matching emails, excluding the records being updated (Id NOT IN :currentIds).
3. Call l.Email.addError('A Lead with this email address already exists.') on duplicates.

Best Practices

• Normalise to lowercase before comparing emails.
• Exclude the current record(s) from the duplicate query on updates.
• Use String.isBlank() — handles null AND empty strings.
• One SOQL — never inside a loop.

Problem Statement

Write a before insert trigger on Contact that copies the parent Account's Description into the Contact's Description field — but only when the Contact's Description is blank.

Requirements

• Fires on before insert only.
• Collect Account Ids from Contacts that have an AccountId.
• Guard empty set before the SOQL query.
• Query Accounts (Id, Description) in one SOQL.
• Build a Map<Id, Account>.
• In second loop: skip Contacts with no AccountId; skip if Contact already has a Description; copy Account Description.

Best Practices

• Two loops — collect then apply — keeps SOQL outside the loop.
• Never overwrite a manually set Contact Description.
• Guard with isEmpty() before the SOQL.

Problem Statement

Implement a Trigger + Handler that auto-formats the Phone field on Contact to US format (XXX) XXX-XXXX whenever a 10-digit number is entered.

Trigger Requirements

• Fire on before insert and before update
• Contains no business logic — delegates entirely to handler

Handler Requirements

• Skip records where Phone has not changed on update (use oldMap)
• Strip all non-digit characters, then format if exactly 10 digits
• If not 10 digits or blank, leave the value unchanged
• Mark the private format helper @TestVisible

Test Class Requirements

• Cover: insert formats phone, update skips unchanged phone, invalid phone unchanged, null phone skipped
• Use Test.startTest()/stopTest()

Problem Statement

Implement a Trigger + Handler that prevents an Opportunity from being set to a closed stage (Closed Won or Closed Lost) when Amount is null.

Trigger Requirements

• Fire on before insert and before update
• Zero logic in the trigger body — one call to the handler

Handler Requirements

• Define closed stages in a Set constant
• Skip records that are not in a closed stage
• Skip records where Amount is not null
• Call opp.Amount.addError() with a clear message

Test Class Requirements

• Assert DmlException thrown for Closed Won with null Amount
• Assert open-stage Opportunity with null Amount saves successfully
• Assert Closed Won with a non-null Amount saves successfully

Problem Statement

Implement a Trigger + Handler that maintains an Open_Opportunity_Count__c field on Account reflecting the number of open (non-closed) Opportunity records linked to each account.

Trigger Requirements

• Fire on after insert, after update, after delete, after undelete
• Use separate method calls per event — if (Trigger.isInsert), if (Trigger.isUpdate), etc.
• Pass Trigger.new / Trigger.old and Trigger.oldMap — never pass Trigger.isDelete as a parameter

Handler Requirements

• One public method per event (onAfterInsert, onAfterUpdate, onAfterDelete, onAfterUndelete)
• Each public method delegates to a private updateCounts method
• Collect all affected Account IDs from both the records list and oldMap (handles reparenting)
• Query open opportunities with IsClosed = false grouped by AccountId using AggregateResult
• Initialise all accounts to 0 in the map before applying query results (handles deletions correctly)
• Single SOQL query — bulk-safe for 200+ records

Test Class Requirements

• Assert count increments on opportunity insert
• Assert count decrements on opportunity delete

Problem Statement

Implement a Trigger + Handler that prevents deletion of a Contact if that contact is linked (via OpportunityContactRole) to a Closed Won Opportunity.

Trigger Requirements

• Fire on before delete only
• Pass Trigger.old to the handler

Handler Requirements

• Collect all Contact IDs being deleted into a Set
• Single SOQL on OpportunityContactRole filtering ContactId IN :contactIds and Opportunity.StageName = 'Closed Won'
• Call con.addError() with a clear message for blocked contacts

Problem Statement

Write an Apex trigger UpdateContactCount on the Contact object that fires on after insert, after delete, and after undelete.

After each event, recalculate the number of Contacts for each affected Account and store the result in a custom field Total_Contacts__c on the Account.

Requirements

• Use a single aggregate SOQL query — no queries inside loops.
• Handle the case where an Account's last Contact is deleted (count → 0).
• Collect Account IDs from Trigger.new on insert/undelete and from Trigger.old on delete.

Problem Statement

Write an Apex trigger LeadUniqueEmailCheck on the Lead object that fires before insert and before update.

If any incoming Lead has an Email that already exists on another Lead record (case-insensitive comparison), block the save with:
"Email must be unique across all Leads."

Requirements

• Case-insensitive comparison (use .toLowerCase()).
• On update, do not flag a Lead against itself.
• Bulk-safe: one SOQL query for all emails in the batch.

Problem Statement

Write an Apex trigger UpdateContactBillingAddress on Account that fires after update.

Whenever any billing address field changes on an Account, copy the new billing address to the mailing address of all related Contact records.

Address Fields to Sync

• Account: BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry
• Contact: MailingStreet, MailingCity, MailingState, MailingPostalCode, MailingCountry

Requirements

• Only update Contacts when at least one billing field actually changed.
• Use Trigger.oldMap to detect changes.
• Bulk-safe — one SOQL and one DML for all affected Accounts.

Problem Statement

Write an Apex trigger CalculateTotalOnCustomObjectA on CustomObjectB__c that fires on after insert, after update, and after delete.

Each CustomObjectB__c record has a lookup to CustomObjectA__c (field: CustomObjectA__c) and a currency field Value__c.

After every change, recalculate and store the sum of all Value__c for each parent in the Total_Value__c field on CustomObjectA__c.

Requirements

• Use an aggregate SOQL with SUM() and GROUP BY.
• Handle delete: use Trigger.old to collect parent IDs.
• Single SOQL and single DML.

Problem Statement

Write an Apex trigger FlagOutOfZip on Account that fires before update.

When an Account's BillingPostalCode changes, check all related Contacts. If any Contact's MailingPostalCode does not match the Account's (new) BillingPostalCode, set Out_of_Zip__c = true on the Account; otherwise set it to false.

Requirements

• Only process Accounts where BillingPostalCode actually changed.
• Bulk-safe: one SOQL query for all affected Accounts.
• This is a before trigger — mutate acc.Out_of_Zip__c directly.

Problem Statement

Write an Apex trigger CreateAccountForOrphanContact on Contact that fires before insert.

If a Contact is being inserted with no AccountId, automatically create a parent Account using the Contact's LastName as the Account name and Phone as the Account phone, then assign the new Account's Id back to the Contact's AccountId.

Requirements

• A before-insert trigger allows direct field assignment — no Contact update DML needed.
• Create all Accounts in one bulk DML insert.
• Maintain order to correctly map each orphan Contact to its new Account.

Problem Statement

Write a trigger UpdateContact on Contact (after update) and a handler class ContactHandler with a static method checkDeadIntel(List<Contact>).

When Contacts are updated, check each related Account: if 70% or more of its Contacts have Dead__c = true, set needintel__c = true on that Account.

Requirements

• Use two separate aggregate queries — one for total count, one for dead count.
• Work out each Account's dead-Contact percentage from those two counts, guarding against division by zero.
• Bulk-safe: handle multiple Contacts from multiple Accounts.
• Single Account update DML.
• Write a test class with at least two test methods verifying both cases.

Problem Statement

Write an Apex trigger UpdateContactProfile on Account that fires after update.

When an Account's Website field changes, update the Profile__c field on all related Contacts using this format:

Profile__c = Website + "/" + FirstInitial + LastName

Example: Website = https://acme.com, Contact = John Smith → Profile__c = "https://acme.com/JSmith"

Requirements

• Only process Accounts where Website actually changed and is not null.
• Bulk-safe — one SOQL, one DML.
• Skip Contacts with a null FirstName.

Problem Statement

Write an Apex trigger MarkGoldAccount on Opportunity that fires on after insert, after update, and after delete.

After each event, check each related Account: if any of its Opportunities has Amount > 20000, set is_gold__c = true on the Account; otherwise set it to false.

Requirements

• Use a single aggregate SOQL with COUNT() and a HAVING clause — or a regular query with Amount > 20000.
• Handle the delete case: use Trigger.old to collect Account IDs.
• Bulk-safe: one SOQL and one DML for all affected Accounts.

Problem Statement

Write a before insert trigger on the standard object Contact that copies the parent Account's Billing address into the Contact's Mailing address fields, but only when the Contact's own mailing address is blank.

Best Practices

• Collect the relevant AccountIds into a Set first.
• Query all needed Accounts in a single SOQL call, then loop the Contacts again to apply the fields.

Objects / Fields

• Contact — AccountId, MailingStreet/City/State/PostalCode/Country
• Account — BillingStreet/City/State/PostalCode/Country

Problem Statement

Write an after insert trigger on the standard object Case that automatically creates a follow-up Task for the Case owner whenever a new Case is logged with Priority = 'High'.

Best Practices

• Build the full list of Tasks first, then insert once — never insert inside the loop.
• after insert is required since the Case needs an Id to link the Task via WhatId.

Objects / Fields

• Case — Priority, OwnerId, CaseNumber
• Task — WhatId, OwnerId, Subject, ActivityDate, Status, Priority

Problem Statement

Write an after update trigger on the standard object Account that cascades a custom field Account_Status__c to all related Contact records whenever it changes on the Account.

Best Practices

• Only recalculate for Accounts whose Account_Status__c actually changed (compare against Trigger.oldMap) — don't cascade on every unrelated edit.
• Query related Contacts with a single SOQL call, update once.

Objects / Fields

• Account — Account_Status__c (custom Text/Picklist)
• Contact — AccountId, Account_Status__c (custom)

Problem Statement

Write a before delete trigger on the standard object Contact that blocks deletion if the Contact is linked to any Opportunity (via OpportunityContactRole) whose StageName is not 'Closed Lost'.

Best Practices

• Use the standard OpportunityContactRole junction — Contact has no direct Opportunity lookup out of the box.
• One SOQL query for all Contacts being deleted, not per record.

Objects / Fields

• Contact, OpportunityContactRole.ContactId, Opportunity.StageName

Problem Statement

Write an after insert trigger on the standard object Task that updates a custom field Last_Activity_Date__c on the related Account (via WhatId) or Contact (via WhoId) to today's date.

Best Practices

• WhatId/WhoId are polymorphic — use getSObjectType() to check which object each Id belongs to before querying/updating.
• Combine Account and Contact updates into a single mixed List<SObject> so one update call handles both.

Objects / Fields

• Task — WhatId, WhoId
• Account.Last_Activity_Date__c, Contact.Last_Activity_Date__c (both custom Date)

Problem Statement

Write a before update trigger on the custom object Project__c that prevents changing Status__c to "Completed" if there are related Task__c records still marked "Open".

Best Practices

• Only check Projects actually transitioning into Completed (compare against oldMap).
• One SOQL query for all such Projects, not per record.

Objects / Fields

• Project__c — Status__c
• Task__c — Project__c (lookup), Status__c

Problem Statement

Write a before insert trigger on the custom object Timesheet__c that prevents saving a new Timesheet if the employee's total hours for that week (existing records + the new batch) would exceed 40.

Best Practices

• Use an aggregate SOQL grouped by Employee and week to get existing totals in one query.
• Track a running total per employee/week key so multiple new Timesheet rows for the same employee/week arriving in the same bulk batch are correctly summed together.

Objects / Fields

• Timesheet__c — Employee__c (lookup), Week_Start_Date__c (Date), Hours__c (Number)

Problem Statement

Write a before delete trigger on the custom object Vendor__c that prevents deletion if there are related Purchase_Order__c records with Status__c = 'Active'.

Best Practices

• One SOQL query for all Vendors being deleted — never per record.

Objects / Fields

• Vendor__c, Purchase_Order__c.Vendor__c (lookup), Purchase_Order__c.Status__c

Problem Statement

Write an after insert, after update trigger on the standard object Opportunity that rolls up the total Amount of all open (IsClosed = false) Opportunities onto a custom field Open_Opportunity_Total__c on the parent Account.

Best Practices

• Only recalculate Accounts whose Opportunities actually changed Amount or StageName — not on every unrelated field edit.
• Use an aggregate SUM(...) query grouped by AccountId — one query regardless of batch size.
• Dedup target Accounts with a Set<Id> so each Account is updated exactly once.

Objects / Fields

• Opportunity — AccountId, Amount, StageName, IsClosed
• Account.Open_Opportunity_Total__c (custom Currency)

Problem Statement

Write a before update trigger on the standard object Case that sets Status to "Escalated" whenever a Case is not already Closed or Escalated, and its CreatedDate is more than 5 days old.

Important Caveat

A trigger only fires on DML. A Case nobody touches for 5 days will never re-enter this trigger on its own. In production, pair this logic with a nightly Scheduled/Batch Apex job that queries stale open Cases and updates them (which then safely re-fires this same trigger). This exercise focuses on the escalation logic itself, assuming the Case is being updated.

Objects / Fields

• Case — Status, CreatedDate (standard)

Problem Statement

Write an after insert, after update, after delete trigger on the custom object Expense__c that rolls up the total Amount__c of all child Expense records onto a custom field Total_Expense__c on the parent Project__c.

Best Practices

• A rollup that only handles insert/update will drift out of sync the moment someone deletes an Expense — cover all three DML contexts.
• Use one aggregate SUM(...) query per context, grouped by Project__c.

Objects / Fields

• Expense__c — Project__c (lookup), Amount__c (Currency)
• Project__c.Total_Expense__c (custom Currency)

Problem Statement

Write an after insert trigger on the custom object Order_Item__c that decrements Quantity_In_Stock__c on the related Product__c, blocking the Order Item with addError() if there isn't enough stock.

Best Practices

• Query the related Products with FOR UPDATE to lock those rows for the duration of the transaction, preventing two simultaneous orders from over-selling the same stock.
• Bulk-safe: one query for all Products referenced in the batch.

Objects / Fields

• Order_Item__c — Product__c (lookup), Quantity__c (Number)
• Product__c.Quantity_In_Stock__c (Number)

Problem Statement

Write an after update trigger on the custom object Contract__c that sends an email alert to the record Owner whenever Contract_Status__c transitions to "Expired".

Best Practices

• Email sending (like any slow, callout-adjacent operation) should not run synchronously inside a trigger's transaction — dispatch it via an @future method.
• Only enqueue the future call for Contracts that actually transitioned into Expired.

Objects / Fields

• Contract__c — Contract_Status__c, OwnerId (standard)

Problem Statement

Write an after insert trigger on the custom object Ticket__c that assigns each new Ticket's owner using round-robin logic across active support agents for its Category__c.

Supporting Objects

This design needs two small helper custom objects to make the round-robin state durable across transactions:

• Support_Agent__c — User__c (lookup to User), Category__c, Active__c (Checkbox)
• Round_Robin_Tracker__c — Category__c, Last_Index__c (Number) — stores the last-assigned agent index per category

Best Practices

• Query the Round_Robin_Tracker__c row with FOR UPDATE so two simultaneous Ticket inserts can't both land on the same agent.
• upsert the tracker so a category with no prior tracker still gets one created.

Objects / Fields

• Ticket__c — Category__c, OwnerId

Problem Statement

Write an after insert trigger on the custom object Feedback__c that calculates the average rating and updates a custom field Average_Rating__c on the related custom object Product__c, handling bulk (200+ record) inserts efficiently without hitting governor limits.

Best Practices

• Use an aggregate AVG(...) query grouped by Product__c — this computes every Product's average in one SOQL call regardless of batch size.
• Dedup target Products with a Set<Id> so each Product is updated exactly once even if dozens of Feedback records in the batch point to the same Product.

Objects / Fields

• Feedback__c — Product__c (lookup), Rating__c (Number)
• Product__c.Average_Rating__c (custom Number)

Problem Statement

Write a trigger PreventOwnerChangeDuringApproval on Account that fires before update.

If an Account's OwnerId is being changed while that Account has a pending approval request (a ProcessInstance with Status = 'Pending'), block the change with addError().

Requirements

• Only check Accounts whose OwnerId is actually changing.
• Use a single bulk SOQL query against ProcessInstance, outside any loop.
• Bulk-safe: handle multiple Account updates in one transaction.

Problem Statement

Write a trigger SyncOpportunityTypeWithSegment on Opportunity that fires on before insert and before update.

Automatically set the Opportunity's Type based on the parent Account's Customer_Segment__c:

• Enterprise → New Customer
• Mid-Market → Existing Customer - Upgrade
• Small Business → Existing Customer - Replacement

Requirements

• Use a single bulk SOQL query against Account, outside any loop.
• Leave Type untouched if the segment doesn't match a known mapping.

Problem Statement

Write a trigger UpdateAccountHealthFromCases on Case that keeps each related Account's Health_Status__c in sync with its open, high-priority Case load.

Whenever an Account has 3 or more open (IsClosed = false) Cases with Priority = 'High', set Health_Status__c to 'Critical'; otherwise set it to 'Healthy'.

Requirements

• Fire on after insert, after update, after delete, and after undelete — any Case change can shift the count.
• Recompute using a single aggregate SOQL query (GROUP BY AccountId), not a loop.
• Bulk-safe: recompute every affected Account in one query and one DML update.

Problem Statement

Write a trigger SyncPrimaryContactPhone on Opportunity that fires on before insert and before update.

Whenever the Opportunity's Primary_Contact__c lookup is set or changed, copy that Contact's Phone into Primary_Contact_Phone__c. If Primary_Contact__c is cleared, clear the phone field too.

Requirements

• Use a single bulk SOQL query against Contact, outside any loop.
• On update, only re-query Contacts whose Primary_Contact__c actually changed.

Problem Statement

Write a trigger FlagAccountsWithExpiringContracts on Contract that fires on after insert and after update.

Set the parent Account's Contract_Expiring__c checkbox to true when any of its Activated Contracts has an EndDate within the next 30 days (inclusive); otherwise set it to false.

Requirements

• Use a single bulk SOQL query against Contract, outside any loop.
• Only consider Contracts with Status = 'Activated'.

A Note on Time-Based Logic

Because "within 30 days" changes as time passes with no record edit at all, a trigger alone can only re-evaluate an Account when one of its Contracts is actually written to. A production implementation would pair this trigger with a nightly Schedulable/Batch job to catch a Contract simply aging into the 30-day window.

Problem Statement

Write a trigger PreventMultiplePrimaryContacts on Contact that fires on before insert and before update.

An Account may have at most one Contact with Is_Primary_Contact__c = true. Block, with addError(), any Contact save that would give an Account a second primary Contact.

Requirements

• Use a single bulk SOQL query against Contact to find each Account's existing primary Contact, outside any loop.
• Bulk-safe: two new Contacts both claiming primary for the same Account in the same transaction must not both be allowed through.
• Updating the Account's existing primary Contact (keeping it primary) must not conflict with itself.

Business Scenario

Frustrated customers sometimes submit the same issue multiple times in quick succession through different channels, creating duplicate Cases. Block a new Case from being created if the same Contact already has a Case created within the last 60 minutes.

Requirements

• Collect all Contact Ids from the inserted Cases first, then run one aggregate query — never query per record.
• Count each Contact's recent Cases created within the last 60 minutes, grouped per Contact.
• Block (via addError) any new Case whose Contact already has a recent Case.

Best Practices

• Bulkify by collecting all Contact Ids into a Set<Id> first, then running a single GROUP BY aggregate query — this scales to a bulk API insert of hundreds of Cases in one query.
• addError() on the new record is the standard way to block a save from a before insert trigger.

Business Scenario

Sales leadership wants each Account's custom field Top_Open_Opportunity_Amount__c to always reflect the largest still-open Opportunity on that Account, updated the moment any Opportunity changes — insert, update, delete, or undelete.

Requirements

• Handle all four trigger contexts: insert, update, delete, undelete.
• Recompute each affected Account's largest still-open Opportunity amount with a single aggregate query covering the whole batch — never one query per Account.
• An Account with no open Opportunities left should reset to 0, not stay stale.

Best Practices

• This must be an after trigger since it re-queries the Opportunity table including the just-changed records.
• Trigger.old is used for the delete context (there is no Trigger.new on delete); every other context uses Trigger.new.
• Recompute from scratch via MAX() rather than comparing only the changed record's Amount — that's the only way a delete of the current top Opportunity correctly falls back to the next-highest one.

Business Scenario

When a Case's Priority becomes "Critical" — either set that way on creation, or changed to it later — create a follow-up Task on the related Account so the account team notices immediately.

Requirements

• Fires on insert (created already Critical) and on update (changed to Critical).
• Must not re-fire on every subsequent edit of an already-Critical Case — only the transition into Critical creates a new Task.
• Skip Cases with no related Account.

Best Practices

• Comparing against Trigger.oldMap is how you detect a genuine transition into a value, rather than firing on every save where the value happens to already be Critical.
• Collect every Task into one list and insert once, outside the loop.

Business Scenario

Reps occasionally create a second Opportunity for the same deal instead of updating the existing one. Flag a new Opportunity as a potential duplicate when the same Account already has another open Opportunity closing in the same month and year.

Requirements

• Collect Account Ids from the new Opportunities first, then run a single aggregate query grouped by Account, close month, and close year.
• Set Potential_Duplicate__c = true on any new Opportunity whose Account+month+year combination already has an existing open Opportunity.
• Skip Opportunities missing an Account or a Close Date.

Best Practices

• CALENDAR_MONTH()/CALENDAR_YEAR() in a GROUP BY aggregate is the standard way to bucket existing records by month without pulling every record into Apex to compare dates manually.
• Building a composite string key (Account + year + month) lets you do one bulk lookup instead of a nested loop comparing every new Opportunity against every existing one.

Business Scenario

Sales leadership wants visibility into every high-value deal that falls through. When an Opportunity with Amount >= 100,000 transitions to Closed Lost, automatically open an internal Case for the team to review what happened.

Requirements

• After update trigger on Opportunity.
• Only fire on a genuine transition into Closed Lost (not already Closed Lost), and only when Amount meets the high-value threshold.
• The Case should reference the Opportunity's Account and summarize the lost deal in its Description.

Best Practices

• Named constant for the high-value threshold, so the bar for "review-worthy" deals is a one-line change.
• Collect all qualifying Cases into a list first and insert once — bulk-safe even if many high-value deals are lost in the same batch update.
• Wrap the insert in try/catch(DmlException).

Business Scenario

Sales operations wants to stop reps from accidentally adding the same Product twice to an Opportunity's line items, which throws off quantity and revenue totals.

Requirements

• Before insert trigger on OpportunityLineItem.
• Block a new line item whose Product2Id already exists on the same Opportunity, using addError().
• Also catch duplicates within the same insert batch — two new line items for the same Opportunity and Product added in one call must not both slip through.

Best Practices

• Query existing line items for all affected Opportunities in a single SOQL call, then check every new line item against the results in memory — no query per record.
• A second in-memory Map tracks products already seen earlier in the same Trigger.new batch, since a same-transaction duplicate would not appear in the existing-records query.

Business Scenario

Customer Success wants a Contact's loyalty tier kept in sync with their total Closed Won purchase history. Opportunities carry a custom lookup Primary_Contact__c to Contact, and Contact has a custom picklist Loyalty_Status__c (Standard/Silver/Gold/Platinum).

Requirements

• After update trigger on Opportunity, firing when an Opportunity transitions into Closed Won.
• Recompute the Contact's total Closed Won Amount (not just this one deal) and set the tier: Platinum ≥ 100,000, Gold ≥ 50,000, Silver ≥ 10,000, else Standard.
• Only update Contacts whose tier actually changes.

Best Practices

• Use an aggregate SUM(Amount) ... GROUP BY Primary_Contact__c query to get each Contact's true lifetime total in one query, rather than summing in Apex from a detail query.
• Compare the computed tier against the Contact's current Loyalty_Status__c before adding it to the update list — skip Contacts whose tier is unchanged to avoid a redundant DML write.
• Wrap the update in try/catch(DmlException).

Business Scenario

Renewals should never fall through the cracks. When a renewable deal (custom checkbox Is_Renewable__c on Opportunity) closes as Closed Won, a follow-up renewal Opportunity should be created automatically one contract term (12 months) out, so the account team has it on their pipeline well in advance.

Requirements

• After update trigger on Opportunity.
• Only act on a transition into Closed Won where Is_Renewable__c is true.
• The new Opportunity copies the Account and Amount, starts in Prospecting, has a CloseDate 12 months after the original, and tracks its origin via a custom lookup Renewed_From__c.

Best Practices

• Collect all renewal Opportunities to insert into a list first, then insert once — bulk-safe even if many renewable deals close in the same transaction.
• Named constant for the renewal term length keeps the "how far out" business rule easy to tune.
• Wrap the insert in try/catch(DmlException).

Business Scenario

Executive sponsors insist that VIP customer Accounts (custom checkbox VIP_Customer__c) can only have their owner reassigned by specially authorized users, to prevent accidental or unauthorized handoffs of the company's most important relationships.

Requirements

• Before update trigger on Account.
• Detect when OwnerId is actually changing on a VIP Account (compare against Trigger.oldMap).
• Block the change with addError() unless the running user holds a custom permission Reassign_VIP_Accounts.

Best Practices

• FeatureManagement.checkPermission() checks a Custom Permission on the running user — a declarative, admin-configurable way to gate this override without hardcoding specific User Ids or Profiles in Apex.
• Use Trigger.oldMap (not a loop-built Map) since before update guarantees it is already populated and index-aligned to Trigger.new by Id.
• Bulk-safe: the permission is checked once, not per record, and every qualifying record in the batch gets its own addError().

Business Scenario

Support leadership wants an Account's Risk_Level__c (custom picklist: Low/Medium/High) to reflect how many open Cases it currently has, recalculated whenever Cases are inserted, updated, deleted, or undeleted.

Requirements

• Trigger on Case for after insert, after update, after delete, after undelete.
• Risk is High with 5+ open Cases, Medium with 2-4, Low otherwise.
• Recompute using the true current open-Case count from the database (not just the records in the trigger batch), since Cases unrelated to this transaction also affect the count.
• Only update Accounts whose computed risk level actually changes.

Best Practices

• Use Trigger.isDelete to pick Trigger.old vs Trigger.new as the source of affected Cases, since Trigger.new is not available in a delete context.
• A single aggregate query grouped by Account gets the authoritative open-Case count per Account, rather than trying to infer it from just the records in the trigger batch.
• Compare the newly computed risk level against the Account's current value before adding it to the update list, avoiding a no-op DML write.

Business Scenario

Deal desk requires at least one supporting file (signed contract, approval memo, etc.) to be attached to an Opportunity before it can be closed, whether won or lost, to maintain an audit trail.

Requirements

• Before update trigger on Opportunity.
• Detect a transition into Closed Won or Closed Lost from any non-closed stage.
• Block the transition with addError() if the Opportunity has zero attached Files (query ContentDocumentLink).

Best Practices

• ContentDocumentLink.LinkedEntityId is how Salesforce Files relate to any parent record — an aggregate COUNT(Id) ... GROUP BY LinkedEntityId query gets attachment counts for every closing Opportunity in one call.
• A Set<String> of closing stage names avoids duplicating the "Closed Won or Closed Lost" check as two separate conditions everywhere it's needed.
• Only Opportunities genuinely transitioning into a closed stage are checked — editing an already-closed Opportunity for an unrelated field should not re-trigger this validation.

Business Scenario

Every Product2 can have one or more related Warranty__c records (custom object: Product__c lookup to Product2, Status__c picklist Active/Discontinued). When a Product is deactivated or reactivated (IsActive changes), every one of its Warranty records must be synchronized to match — discontinued products should never keep an "Active" warranty.

Requirements

• After update trigger on Product2.
• Only act when IsActive actually changed on the Product.
• Update every related Warranty__c's Status__c to match the Product's new active state, skipping Warranties that already match.

Best Practices

• Detect the real field-level change (IsActive differs from Trigger.oldMap) before doing any query — Products saved with unrelated field edits should not trigger a Warranty sync at all.
• One SOQL query pulls every affected Warranty for every changed Product, and one bulk DML call updates them — no per-Product query or update.
• Skip Warranties whose Status__c already matches the expected value to avoid a no-op write.