Queueable Apex Practice Problems

Problem Statement

Write OpportunityHealthScoreQueueable that implements Queueable and recalculates a custom Health_Score__c field on a set of Opportunities.

Scoring Rules

• +30 if Amount ≥ 50,000
• +20 if CloseDate ≥ today (not in the past)
• +25 if StageName is 'Proposal/Price Quote' or 'Value Proposition'
• +50 if StageName is 'Closed Won'

Requirements

• Implement Queueable.
• Constructor accepts Set<Id> opportunityIds.
• execute(QueueableContext context): guard empty input, query Opps, compute score, bulk update.

Best Practices

• SOQL and DML outside loops.
• Guard with isEmpty() before DML.
• Enqueue: System.enqueueJob(new OpportunityHealthScoreQueueable(ids));

Problem Statement

Implement the chained Queueable pattern with two classes:

1. AccountTierQueueable — sets Revenue_Tier__c on Accounts, then chains to ContactTagQueueable.
2. ContactTagQueueable — sets Contact_Segment__c = 'Processed' on related Contacts.

Requirements

• Both classes implement Queueable.
• Both accept Set<Id> accountIds via constructor.
• AccountTierQueueable.execute(): update Revenue_Tier__c per scoring rules, then call System.enqueueJob(new ContactTagQueueable(accountIds)) guarded by !Test.isRunningTest().
• ContactTagQueueable.execute(): set Contact_Segment__c = 'Processed' on all Contacts whose AccountId IN :accountIds.

Best Practices

• Guard chaining with if (!Test.isRunningTest()) — you cannot enqueue from within a Queueable during test execution without wrapping in Test.startTest()/stopTest().
• All SOQL and DML outside loops.

Problem Statement

Write OpportunityStageUpdateQueueable that updates a batch of Opportunities to a target StageName. If the DML fails, re-enqueue itself up to MAX_RETRIES = 3 times.

Requirements

• Implement Queueable.
• Constructor: (List<Id> opportunityIds, String targetStage, Integer retryCount).
• Declare private static final Integer MAX_RETRIES = 3.
• execute(): guard empty input and blank stage; skip records already at the target stage; wrap DML in try-catch; on failure re-enqueue if retryCount < MAX_RETRIES guarded by !Test.isRunningTest().

Best Practices

• Skip records that are already at the target stage — avoids unnecessary DML.
• Log the attempt number in the error message for debugging.
• Re-enqueue with retryCount + 1 — never modify the field directly before the retry call.

Business Scenario

When a Case is created, support agents want to immediately see a snapshot of the related Account's tier and revenue directly on the Case — without a slow synchronous lookup blocking the save. Do the enrichment asynchronously via Queueable Apex.

Requirements

• Write a class CaseEnrichmentQueueable implementing Queueable, constructed with a Set<Id> caseIds.
• execute() re-queries the given Cases, collects their related Account Ids, and looks up each Account's Tier__c and AnnualRevenue.
• Copies those values onto Account_Tier_Snapshot__c and Account_Revenue_Snapshot__c on each Case, bulk-updated.

Best Practices

• Queueable jobs receive only serializable constructor state (like a Set<Id>) — never pass live SObject records expecting them to reflect the latest committed data; re-query inside execute() instead.
• A Map<Id, Account> built from one bulk query gives O(1) lookups per Case instead of querying per record.