Schedulable Apex Practice Problems

Problem Statement

Write a Schedulable class DailyLeadCleanupScheduler that launches FlagStaleLeadsBatch when it fires.

Add a static helper scheduleIdempotent(String cronExpression) that can be called any number of times without ever creating duplicate scheduled jobs — it should abort any existing job with the same name before scheduling a new one.

Requirements

• execute(SchedulableContext ctx) calls Database.executeBatch(new FlagStaleLeadsBatch(), 200).
• A public static final String JOB_NAME constant names the job consistently.
• scheduleIdempotent(cronExpression): query CronTrigger joined to CronJobDetail.Name for the job name, call System.abortJob() on any match, then System.schedule(...) a fresh run and return its Id.

Best Practices

• Re-running setup code (e.g. a deployment post-install script, or an admin clicking a "reschedule" button twice) is a very common way scheduled jobs end up duplicated — aborting-then-rescheduling by name is the standard fix.
• Query CronTrigger via its relationship to CronJobDetail.Name rather than trying to track job Ids yourself across deploys.
• Keep the job name as one named constant so the scheduling code and the lookup query can never drift out of sync.

Problem Statement

Write a Schedulable class NightlyStaleLeadLauncher whose only job is to launch FlagStaleLeadsBatch every time it fires.

Requirements

• Implement Schedulable.
• execute(SchedulableContext ctx) calls Database.executeBatch(new FlagStaleLeadsBatch(), 200).

Best Practices

• Keep the Schedulable class this thin on purpose — it's just a trigger for the batch, not a place to put business logic.
• A cron expression like '0 0 2 * * ?' (2:00 AM daily) is passed to System.schedule(...) separately, one time, outside this class — the class itself doesn't need to know its own schedule.

Problem Statement

Write a Schedulable class HourlyMonitorJob that logs the number of open Cases, then reschedules itself to run again exactly one hour later — unless a Custom Setting says to stop.

Requirements

• execute() logs the current count of open Cases via System.debug.
• Check a hierarchy Custom Setting Monitor_Settings__c — if its Stop_Scheduling__c checkbox is true, do not reschedule and return immediately.
• Otherwise, compute a cron expression for exactly one hour from now and call System.schedule(...) with a unique job name (each run's job name must differ, since a fixed name would collide with the still-existing prior job).

Best Practices

• Self-rescheduling without a stop condition is a classic way to create a job that runs forever with no clean way to turn it off except manually aborting the CronTrigger — always build in an explicit off-switch.
• Each scheduled instance needs a unique job name (e.g. suffixed with a timestamp) — reusing the same name while the previous run's job might still be registered throws a duplicate-job error.
• Do the real work before deciding whether to reschedule, so the very last run (the one that decides to stop) still completes its job.

Business Scenario

The renewals team wants a nightly log of every active Contract expiring within the next 30 days, so they can proactively reach out before contracts lapse.

Requirements

• ContractExpirationDigestScheduler (Schedulable) launches ContractExpirationDigestBatch when it fires.
• The batch queries Contracts that are currently in Activated status and whose EndDate falls within the next 30 days (today through today+30, inclusive).
• For each matching Contract, insert one Contract_Expiration_Log__c record capturing the Contract, its Account, the expiration date, and when it was logged.

Best Practices

• Keep the Schedulable thin — its only job is to launch the batch that does the real work.
• Bound the date window on both ends so already-expired Contracts don't get logged again every night.

Business Scenario

Compliance wants a nightly point-in-time snapshot of every Account, in case a bad data-load or user error needs to be rolled back manually. Apex cannot write to a real filesystem, so this is modeled as a nightly export into a custom log object, Backup_Log__c.

Requirements

• Write DailyAccountBackupScheduler implementing Schedulable, firing daily at 2 AM via CRON_EXPRESSION = '0 0 2 * * ?'.
• execute() queries all Accounts and serializes each one to JSON into a Backup_Log__c.Snapshot_Data__c field, along with Source_Record_Id__c, Object_Type__c, and today's Backup_Date__c.
• Insert all snapshot records with a single bulk DML call.
• Provide scheduleDailyBackup() to register the job via System.schedule.

Best Practices

• JSON.serialize(a) captures the full record state in one field without needing a rigid schema per object type — a pragmatic way to model "backup" inside Apex's record-based model.
• All snapshot records are built in memory and inserted with one bulk DML call, never per record.
• Wrap the insert in try/catch(DmlException) so a bad chunk doesn't silently crash the whole scheduled job.

Business Scenario

Leadership wants a lightweight weekly pulse on customer growth — new Accounts created and deals closed in the last 7 days — emailed automatically every Monday morning.

Requirements

• Write WeeklyCustomerReportScheduler implementing Schedulable, firing every Monday at 6 AM via CRON_EXPRESSION = '0 0 6 ? * MON'.
• Count Accounts created in the last 7 days, and Opportunities that reached Closed Won in the last 7 days, using SELECT COUNT().
• Guard against a blank recipient email before attempting to send.
• Send a single summary email via Messaging.SingleEmailMessage, wrapped in try/catch.

Best Practices

• SELECT COUNT() avoids pulling full record data into memory just to count rows.
• Guarding on a blank recipientEmail before building/sending the email avoids a wasted Messaging.sendEmail call that would simply fail.
• Wrapping the send in try/catch(Exception) keeps a transient email-service issue from surfacing as a hard job failure.

Business Scenario

Sales managers keep losing track of Opportunities that have gone quiet. Every morning, a scheduled job should create a follow-up Task for the owner of any open Opportunity with no activity in the last two weeks.

Requirements

• Write DailyOpportunityReminderScheduler implementing Schedulable, firing daily at 7 AM via CRON_EXPRESSION = '0 0 7 * * ?'.
• An Opportunity qualifies when it's open (IsClosed = false) and LastActivityDate is more than NO_ACTIVITY_DAYS (14) days old, or was never set.
• Create one Task per qualifying Opportunity, assigned to its OwnerId, linked via WhatId, with Priority = 'High'.
• Insert all Tasks in a single bulk DML call.

Best Practices

• Filtering directly in SOQL (IsClosed = false, the activity-date window) keeps each run's working set small instead of pulling every Opportunity and filtering in Apex.
• All Task records are assembled in a list first; the single insert reminders; call outside the loop keeps this governor-safe at any Opportunity volume.
• Wrap the DML in try/catch(DmlException) so a validation rule on one Task doesn't take down the whole scheduled run.

Business Scenario

Data quality flags Accounts missing key fields with Needs_Review__c = true. Once a rep fills in the missing Website and Phone, the stale flag is never cleared automatically. A nightly job should clear it once both fields are populated.

Requirements

• Write NightlyAccountCleanupScheduler implementing Schedulable, firing daily at 1:30 AM via CRON_EXPRESSION = '0 30 1 * * ?'.
• Query only Accounts where Needs_Review__c = true and both Website and Phone are now populated.
• Clear Needs_Review__c back to false for each one.
• Perform the update as a single bulk DML call.

Best Practices

• Filtering for "both fields now populated" directly in SOQL means the job only ever touches Accounts that genuinely need the flag cleared.
• One bulk update call outside any loop keeps this governor-safe regardless of how many Accounts qualify on a given night.
• Wrap the DML in try/catch(DmlException) to isolate a bad record from failing the whole scheduled run.

Business Scenario

Billing needs one Invoice__c generated on the first of every month for each Active Contract__c with a flat monthly fee. Unlike the annual Batch Apex invoice run, the monthly population is small enough that this Schedulable class performs the whole generation itself, without launching a separate batch.

Requirements

• Write MonthlyInvoiceScheduler implementing Schedulable, firing on the 1st of each month at 3 AM via CRON_EXPRESSION = '0 0 3 1 * ?'.
• Query Active Contracts with a non-null Monthly_Fee__c.
• Idempotency: skip any Contract that already has an Invoice__c for the current month/year.
• Create one Invoice__c per remaining Contract with Amount__c = Monthly_Fee__c and Status__c = 'Draft'.
• Insert all invoices in a single bulk DML call.

Best Practices

• Checking for an existing invoice per Contract/month/year before inserting makes the job safe to re-run (e.g., after a manual retry) without generating duplicates.
• Because this Schedulable does real record-generation work (not just launching a batch), it still follows Batch-style bulkification: one query for Contracts, one for existing invoices, one bulk insert — never per-record SOQL/DML.
• Keep the cadence obvious from the CRON_EXPRESSION itself — day-of-month 1 plus a fixed hour reads as "first of the month" without extra comments.

Business Scenario

Warehouse operations wants Product2.Inventory_Status__c refreshed every night to reflect current stock levels, so sales reps see an accurate "In Stock / Low Stock / Out of Stock" badge without a real-time integration.

Requirements

• Write DailyInventoryRefreshScheduler implementing Schedulable, firing daily at 4 AM via CRON_EXPRESSION = '0 0 4 * * ?'.
• Process all active Products (IsActive = true).
• Status rule: 0 or less → Out of Stock; at or below LOW_STOCK_THRESHOLD (10) → Low Stock; otherwise In Stock.
• Only update Products whose computed status differs from the current value.

Best Practices

• A named constant (LOW_STOCK_THRESHOLD) keeps the low-stock cutoff easy to tune without touching the status logic itself.
• Comparing the computed status to the current value before adding to toUpdate avoids no-op DML on Products whose stock level hasn't crossed a threshold.
• One bulk update call outside the loop, wrapped in try/catch(DmlException).

Business Scenario

Sales operations maintains a state-to-territory mapping and wants Accounts automatically re-aligned to the correct Territory__c lookup once a month, since reps sometimes leave it blank or stale after a BillingState change.

Requirements

• Write MonthlyTerritoryAssignmentScheduler implementing Schedulable, firing on the 1st of each month at 5 AM via CRON_EXPRESSION = '0 0 5 1 * ?'.
• Maintain an in-memory Map<String, String> of BillingState (two-letter code) to territory name (e.g. West/South/Northeast/Central).
• Query all Territory__c records once to resolve territory name → Id.
• Query Accounts with a non-null BillingState; reassign Territory__c only when the resolved territory Id differs from the current value.

Best Practices

• Resolving territory names to Ids via one bulk Territory__c query (into a Map) avoids hardcoding Salesforce record Ids, which differ across orgs/sandboxes.
• States with no mapping entry, or territories that don't exist yet, are safely skipped instead of throwing — a partial rollout of new territories doesn't break the whole job.
• Comparing against the Account's current Territory__c avoids reassigning (and re-triggering automation on) Accounts that already have the right territory.

Business Scenario

The reconciliation logic against staged ERP data needs to run automatically every night, not just on demand. This problem is the Schedulable-launches-a-Batch pattern: a thin Schedulable class whose only job is to kick off the batch reconciliation job on a fixed daily cadence.

Requirements

• Write DailyErpSyncScheduler implementing Schedulable, firing daily at 1 AM via CRON_EXPRESSION = '0 0 1 * * ?'.
• execute(SchedulableContext sc) must do nothing except call Database.executeBatch(new ErpSyncBatch(), BATCH_SCOPE_SIZE) and log the returned batch job Id.
• Include the ErpSyncBatch class it launches, implementing Database.Batchable<SObject> against unreconciled ERP_Sync_Log__c rows.
• Provide scheduleDailySync() to register the Schedulable job.

Best Practices

• A Schedulable's execute() should stay thin when its real job is to hand off to a Batch — the Batch, not the Schedulable, is where governor-limit-sensitive bulk work belongs.
• Using a named constant (BATCH_SCOPE_SIZE) for the batch's chunk size keeps it easy to tune independently of the scheduling cadence.
• Even the launched batch keeps its own DML bulkified and wrapped in try/catch(DmlException) — launching from a Schedulable doesn't relax those rules.

Business Scenario

Legal requires every Contact with an email on file to have a recorded consent date and a signed data-processing agreement. A weekly job should detect violations, log them for audit trail purposes, and flag/unflag the Contact so reports stay accurate as records are fixed.

Requirements

• Write ComplianceAuditScheduler implementing Schedulable, firing weekly on Sunday at 3 AM via CRON_EXPRESSION = '0 0 3 ? * SUN'.
• A Contact with an email violates compliance if Consent_Date__c is null, or Data_Processing_Agreement__c is not true.
• For each newly-violating Contact, set Compliance_Flag__c = true and insert a Compliance_Violation__c record capturing the specific reason(s).
• For a Contact that is no longer violating but is still flagged, clear Compliance_Flag__c back to false (no new violation record).
• Perform all Contact updates and violation inserts as separate single bulk DML calls.

Best Practices

• Recording why a Contact is out of compliance (via Violation_Reason__c) makes the audit trail actually useful instead of a generic pass/fail flag.
• Only writing a new violation record when the flag transitions to true avoids duplicate violation rows on every single weekly run for the same ongoing issue.
• Un-flagging Contacts that have since been fixed keeps compliance dashboards trustworthy.
• Two focused bulk DML calls (Contact updates, Violation inserts) — never per-record DML.

Business Scenario

A multi-region sales org wants each Regional Manager to receive their own weekly sales summary email — scoped only to their region's Closed Won results — dispatched from a single scheduled job rather than one job per region.

Requirements

• Write MultiRegionReportScheduler implementing Schedulable, firing every Monday at 6 AM via CRON_EXPRESSION = '0 0 6 ? * MON'.
• Aggregate the last 7 days of Closed Won Opportunity revenue and deal count per region with a single GROUP BY Account.Region__c query.
• Query all Regional_Manager__c records with a non-null Manager_Email__c.
• Build one region-scoped email per manager (region with zero deals still gets an email reporting zero), and send them all in a single Messaging.sendEmail call.

Best Practices

• One aggregate query grouped by region, rather than one query per region, keeps this governor-safe regardless of how many regions exist.
• Building a Map<String, AggregateResult> keyed by region lets each manager's email be assembled with an O(1) lookup instead of a nested loop/query per manager.
• Batching every manager's email into one list and calling Messaging.sendEmail(emails) once respects the single-transaction email limit far better than sending one at a time.

Business Scenario

Finance needs open Invoices automatically reconciled against completed Payments every night: fully-paid invoices should close themselves out, and any overpayment should be logged for manual review rather than silently ignored.

Requirements

• Write FinancialReconciliationScheduler implementing Schedulable, firing daily at 2 AM via CRON_EXPRESSION = '0 0 2 * * ?'.
• Query open Invoices (Status__c IN ('Draft','Sent')).
• Aggregate completed Payment__c totals per Invoice with one GROUP BY Invoice__c query.
• If the paid total matches the invoice amount within AMOUNT_TOLERANCE (0.01), mark the Invoice Paid.
• If the paid total exceeds the invoice amount beyond tolerance, log a Reconciliation_Discrepancy__c record (type Overpayment) instead of silently marking it paid.

Best Practices

• A small AMOUNT_TOLERANCE avoids treating floating-point/rounding noise as a real discrepancy.
• Explicitly logging overpayments (rather than just marking them Paid) surfaces a real financial issue for a human to review instead of hiding it.
• One aggregate query for all Payments in the invoice set, and two focused bulk DML calls (Invoice update, Discrepancy insert) — never per-record SOQL or DML.