Batch Apex Practice Problems

Problem Statement

Write YearlySalesPerformanceBatch that aggregates total Closed Won Opportunity revenue for the current calendar year per Account and writes the result to each Account's Description field.

Requirements

• Implement Database.Batchable<SObject> and Database.Stateful.
• Declare private Map<Id, Decimal> accountAmountMap to accumulate totals.
• execute(): accumulate Amount — no DML here.
• finish(): bulk update Accounts; System.debug the count — visible in the Output tab.

Problem Statement

Write InactiveAccountsBatch that marks Accounts as inactive when they have not been modified in 5 years AND have no open Opportunities.

Requirements

• Implement Database.Batchable<SObject>.
• Overloaded constructors (no-arg defaults to 5 years ago; overload accepts custom DateTime).
• start(): select Accounts whose LastModifiedDate is older than the cutoff and that have no open Opportunities — use an anti-join subquery, not an Apex loop.
• execute(): stamp Description = '[INACTIVE ACCOUNT] Reviewed: ' + today; bulk update outside loop.
• finish(): System.debug the job ID — visible in the Output tab.

Problem Statement

Write ArchiveClosedCasesBatch that stamps the Description of all closed Cases whose ClosedDate is older than 2 years.

Requirements

• Implement Database.Batchable<SObject>.
• No-arg constructor (cutoff = 2 years ago); overloaded constructor accepting custom DateTime.
• start(): select closed Cases whose ClosedDate is older than the cutoff.
• execute(): stamp [ARCHIVED]; bulk update outside loop.
• finish(): System.debug the job ID — visible in the Output tab.

Problem Statement

Write UpdateOpportunityProbabilityBatch that sets Probability for every Opportunity based on StageName using a static map.

Stage → Probability

• Prospecting→10, Qualification→20, Needs Analysis→30, Value Proposition→40
• Id. Decision Makers→50, Perception Analysis→60, Proposal/Price Quote→70, Negotiation/Review→80
• Closed Won→100, Closed Lost→0

Requirements

• Declare the map as private static final Map<String, Integer>.
• start(): query only Opportunities whose StageName is a key in STAGE_PROBABILITY_MAP, using the map's key set as the filter.
• execute(): guard with isEmpty() before DML.
• finish(): System.debug the job ID — visible in the Output tab.

Problem Statement

Write MassLeadAssignmentBatch that assigns all open non-converted Leads to a list of owners in round-robin order across all batch chunks.

Requirements

• Implement Database.Batchable<SObject> and Database.Stateful.
• Constructor accepts List<Id> ownerIds; throws IllegalArgumentException if null/empty.
• Stateful assignmentIndex = 0 persists across chunks.
• execute(): Math.mod(assignmentIndex, ownerCount); bulk update outside loop.
• finish(): System.debug total assigned — visible in the Output tab.

Problem Statement

Write CleanDuplicateContactsBatch that removes duplicate Contacts within the same Account by the composite key AccountId + Email (case-insensitive). Keep the oldest Contact per group; delete the rest.

Requirements

• Implement Database.Batchable<SObject>.
• start(): query only Contacts that have both an AccountId and an Email, sorted so records sharing the same Account and Email are adjacent and the oldest one in each group comes first.
• execute(): group by AccountId + '|' + email.toLowerCase(); keep index 0; delete the rest with Database.delete(list, false).
• finish(): System.debug the job ID — visible in the Output tab.

Problem Statement

Write two Batch Apex classes that run as a two-step pipeline:

1. RecalculateAccountRevenueBatch — recomputes each Account's AnnualRevenue as the sum of its Closed Won Opportunity Amounts.
2. AccountTierBatch — sets each Account's Rating to Hot/Warm/Cold based on the (now up-to-date) AnnualRevenue.

The first batch's finish() method should chain the second batch — but only if the first batch actually changed something.

Requirements

• RecalculateAccountRevenueBatch implements Database.Batchable<SObject>, Database.Stateful so it can track how many Accounts were updated across all batch chunks.
• Aggregate the Closed Won total per Account with one GROUP BY query per execute() call — never query per record.
• In finish(), call Database.executeBatch(new AccountTierBatch(), 200) only when accountsUpdated > 0.

Best Practices

• Chaining unconditionally wastes a full batch job (and its own governor-limit budget) when there was nothing to do — always guard the chain with a real condition.
• Database.Stateful is required to keep a running counter across chunks — without it, every execute() call gets a fresh instance.
• Wrap DML in try/catch(DmlException).

Problem Statement

Write a Batch Apex class SpecificAccountsBatch that processes only a caller-supplied list of Account Ids (passed into the constructor), stamping each one's Description to mark it as reviewed.

Instead of returning a Database.QueryLocator from start(), implement it using a custom Iterable<SObject> — AccountIterable and AccountIterator — to practice the pattern used when a batch's scope isn't a plain SOQL query result.

Requirements

• SpecificAccountsBatch(List<Id> accountIds) constructor stores the Ids.
• start() returns Iterable<SObject>, backed by an AccountIterable wrapping the queried Accounts.
• AccountIterable implements Iterable<SObject> and returns an AccountIterator.
• AccountIterator implements Iterator<SObject> with hasNext() and next().
• execute() sets Description = 'Reviewed via curated batch run'.

Best Practices

• A custom Iterable is the right tool when the batch's working set comes from more than "run this one SOQL query" — e.g. a pre-curated list, records merged from multiple queries, or synthetic data. For a plain SOQL scan, Database.QueryLocator is simpler and should still be preferred.
• Still do the actual record query once inside start(), not once per iterator step — the iterator just walks an already-fetched, in-memory list here.
• Bulk DML outside the loop, wrapped in try/catch(DmlException).

Problem Statement

Write a Batch Apex class UpdateOpportunityDiscountBatch that sets Discount__c on every open Opportunity — 10 if Amount > 100000, otherwise 5.

Any record that fails to update must be captured (not silently dropped) and written to a custom object Batch_Error_Log__c once the job finishes.

Requirements

• Implement Database.Batchable<SObject>, Database.Stateful — a running List<String> failureMessages must survive across every chunk.
• Update with Database.update(scope, false) (partial success) instead of a plain update scope; — inspect each Database.SaveResult for failures and append a descriptive message per error.
• finish(): if any failures were recorded, bulk-insert one Batch_Error_Log__c per failure message (fields: Message__c, Batch_Job__c).

Best Practices

• allOrNone = false means one bad record in a chunk doesn't roll back every other record in that same chunk — essential for large batch jobs processing imperfect data.
• Database.Stateful is required here too — without it, failureMessages would reset to empty on every chunk and finish() would only ever see the last chunk's failures.
• Insert the error log records once in finish(), not per chunk — keeps the log tidy and avoids DML inside execute() beyond the primary update.

Problem Statement

Write a Batch Apex class SyncAccountsCalloutBatch that pushes every Account with Sync_Status__c = 'Pending' to an external CRM via a single bulk HTTP callout per chunk, then stamps each Account as Synced or Failed based on the response.

Requirements

• Implement Database.Batchable<SObject>, Database.AllowsCallouts — the second interface is required for any HTTP callout inside a batch job.
• execute(): build one JSON payload covering the whole scope and send one callout — never one callout per record.
• On a 200 response, mark every Account in the chunk Synced; otherwise (bad status code, or a caught CalloutException) mark them Failed.
• Use a Named Credential-style callout endpoint (callout:External_CRM/...), never a hardcoded URL.

Best Practices

• Batch Apex enforces its own 100-callout limit per execute() transaction — one callout per chunk (not per record) is what keeps that safe at any batch size.
• Because each callout consumes real time, choose a small batch size when calling Database.executeBatch(new SyncAccountsCalloutBatch(), 10) rather than the default 200, to stay within callout timeout limits per transaction.
• Named Credentials (callout:External_CRM) keep the endpoint and auth out of source code — never hardcode the raw URL or credentials.
• Always handle CalloutException — a network failure must not crash the whole batch chunk.

Problem Statement

Write a Batch Apex class FlagStaleLeadsBatch that sets Status = 'Stale' on every non-converted Lead whose LastActivityDate is more than 90 days old (or was never set at all).

Requirements

• Implement Database.Batchable<SObject> with all three methods.
• start(): compute the 90-day cutoff Date once, bind it into the query.
• execute(): set Status = 'Stale' in the loop, then a single bulk update outside it.

Best Practices

• Compute the cutoff Date once per start() call, not inline inside the SOQL string.
• Filter out Leads that have already converted so the batch doesn't waste chunks on records that no longer need attention.
• Wrap the update in try/catch(DmlException).

Problem Statement

Write a Batch Apex class CloseStaleOpportunitiesBatch that closes (as Closed Lost) every open Opportunity whose CloseDate is more than 180 days in the past, and stamps each affected Opportunity's parent Account with a note that it had a stale deal auto-closed.

Requirements

• start(): query open Opportunities with CloseDate older than a 180-day cutoff.
• execute(): build the Opportunity updates and collect the related AccountIds in the same loop; run the Opportunity update.
• Then, in a separate step, build and run the Account update — never put two different SObject types in the same list/DML call.

Best Practices

• Apex DML statements operate on one SObject type at a time — mixing Opportunity and Account records into a single list and calling update on it throws a runtime error, so this always needs two separate bulk DML calls.
• Collect the related Account Ids into a Set<Id> in the same pass you build the Opportunity updates — don't re-loop or re-query for something you already have on hand.
• Wrap both DML calls in their own try/catch(DmlException) — a failure updating Accounts shouldn't be conflated with (or silently hide) a failure updating Opportunities.

Business Scenario

Premium-tier support is expensive to staff. Any Account still marked Tier__c = 'Premium' that hasn't had any activity in 180 days should be automatically downgraded to 'Standard'.

Requirements

• Only targets Accounts currently on the Premium tier.
• Includes Accounts whose last activity is stale (more than 180 days old), and Accounts that have never had any activity at all.
• Sets Tier__c = 'Standard'.

Business Scenario

A departing sales rep's entire book of Accounts needs to move to a replacement rep, with a permanent audit record of the change for compliance. Write a Batch Apex class ReassignAccountOwnerBatch that moves every Account owned by one User to another, logging each change to a custom object Account_Ownership_Log__c.

Requirements

• Constructor takes fromOwnerId and toOwnerId.
• start() queries every Account currently owned by fromOwnerId.
• execute() reassigns OwnerId and inserts one Account_Ownership_Log__c per Account, capturing the old owner, new owner, and timestamp.

Best Practices

• Capture the old owner value before building the update — once you reassign OwnerId in memory, the original value is gone unless you record it first.
• Two separate DML calls (Account update, log insert) since they're different SObject types — never mix them in one list.

Business Scenario

A one-time data backfill needs to compute Territory_Code__c for every Account missing it, derived from Region__c. Given the volume, some records may fail (validation rules, field-length limits) — track failures, log them, and automatically retry by re-launching the batch (since a fresh start() query will only pick up Accounts still missing Territory_Code__c, which naturally excludes everything that already succeeded).

Requirements

• Implements Database.Batchable<SObject>, Database.Stateful to track running success/failure counts across all chunks.
• Derives Territory_Code__c as the first 3 letters of Region__c, uppercased (or 'UNK' if Region__c is blank).
• Uses Database.update(scope, false) so one bad record doesn't block the rest of the chunk; records every failure's message.
• In finish(), if there were any failures: log them all to Batch_Error_Log__c, then re-launch the batch to retry — since start()'s query only ever selects Accounts still missing Territory_Code__c, the retry naturally covers just the leftover failures.

Best Practices

• Designing start()'s query to be self-limiting (only ever selects remaining incomplete work) is what makes "re-launch on failure" safe — it can never re-process already-successful records or loop forever once everything succeeds.
• Database.Stateful is required to keep recordsProcessed/ recordsFailed accurate across every chunk of a potentially large job.

Business Scenario

Every night, recompute every Account's revenue-based tier (Standard / Gold / Platinum). Any Account that newly reaches Platinum should generate a follow-up Task for its owner — but the notification step should only look at the Accounts that actually changed, not re-scan the whole org.

Requirements

• AccountTieringPipelineBatch (Database.Batchable<SObject>, Database.Stateful): recomputes Tier__c for every Account (Platinum >= 10,000,000 revenue, Gold >= 1,000,000, else Standard), tracking the Ids of Accounts that newly became Platinum this run.
• In finish(), if any Accounts newly reached Platinum, enqueue PlatinumUpgradeNotifyQueueable with just those Ids.
• PlatinumUpgradeNotifyQueueable re-queries those Accounts and creates one Task per Account for its owner.

Best Practices

• Chaining a Queueable from a batch's finish() (rather than another Batch) is the right choice here — the follow-up work (a handful of Task inserts) is small and doesn't need its own governor-limit-scoped chunks.
• Passing only the changed Account Ids to the Queueable — not re-deriving "who's Platinum" from scratch — keeps the notification step's query scope minimal.
• Only update an Account when its tier actually changed (newTier != a.Tier__c), avoiding a no-op DML write on every single Account every night.

Business Scenario

Data governance wants a reusable batch that can check any set of field-level rules against Accounts — e.g. "Website must look like a URL", "Phone must be 10+ digits" — without writing a new batch class every time a rule is added. Build it around a caller-supplied list of rules, evaluated dynamically via generic field access.

Requirements

• DataQualityRule: a simple data class holding fieldName and requiredPattern (a regex the field's value must match).
• DataQualityRuleRunnerBatch constructed with List<DataQualityRule> rules.
• start() dynamically builds its SELECT clause from every rule's fieldName (plus Id), so the batch works for whatever fields the caller's rules reference — no hardcoded field list.
• execute(): for each Account and each rule, read the field's value via SObject.get(fieldName), and if it doesn't match the rule's requiredPattern, insert a Data_Quality_Violation__c recording the record, field name, and offending value.

Best Practices

• Building the SELECT clause dynamically from the rules list is what makes this batch reusable — adding a new field-level rule never requires touching this class again.
• SObject.get(fieldName) + Pattern.matches() is the standard pattern for evaluating a field generically without knowing its name at compile time.
• Guard against a null field value by converting to an empty string before pattern matching, rather than letting a null reach Pattern.matches().

Business Scenario

Sales operations wants Account.Customer_Status__c refreshed once a month so reps can trust it reflects real recent engagement, not whatever was set at Account creation.

Requirements

• Write MonthlyCustomerStatusBatch implementing Database.Batchable<SObject>.
• An Account is Active if LastActivityDate is within the last INACTIVITY_DAYS (90) days; otherwise it is Dormant.
• Only add an Account to the update list when its current Customer_Status__c actually differs from the computed value.
• execute() must issue a single bulk update call, never DML per record.

Best Practices

• A named constant (INACTIVITY_DAYS) instead of a bare 90 keeps the rule self-documenting and easy to tune later.
• Skipping Accounts whose status wouldn't change avoids no-op DML rows and keeps audit/history trails clean.
• Wrap the bulk update in try/catch(DmlException) so one bad chunk doesn't surface an unhandled exception in the job's history.

Business Scenario

Marketing wants stale, never-responded CampaignMember records purged periodically so Campaign response-rate reports stay meaningful and lists don't grow unbounded.

Requirements

• Write DeleteExpiredCampaignMembersBatch implementing Database.Batchable<SObject>.
• Target only CampaignMembers created more than EXPIRATION_DAYS (180) days ago that never responded (HasResponded = false).
• execute() must delete the whole scope in a single bulk DML call.

Best Practices

• Filtering in start()'s query (rather than in Apex after querying everything) keeps each chunk small and avoids wasting governor limits on records that won't be touched.
• A single delete scope; call handles the whole chunk in one DML statement — never delete inside a loop.
• Wrap the delete in try/catch(DmlException) so a locked record in one chunk doesn't silently kill the whole job.

Business Scenario

Finance wants product list prices adjusted once a year by a per-product inflation rate stored on a custom field, instead of manually editing every Product2 record.

Requirements

• Write AnnualPriceAdjustmentBatch implementing Database.Batchable<SObject>, Database.Stateful to track how many products were adjusted across all chunks.
• Only process active Products that have a non-null Annual_Adjustment_Percent__c.
• New price = Standard_Price__c * (1 + Annual_Adjustment_Percent__c / 100), rounded to 2 decimal places.
• Skip Products with a null Standard_Price__c instead of erroring.

Best Practices

• Database.Stateful is required for productsAdjusted to survive across every execute() chunk — without it the counter resets to 0 each time.
• Filtering Annual_Adjustment_Percent__c != null in the query keeps the batch from wasting chunks on Products that would never change.
• setScale(2) avoids floating-point noise accumulating in currency fields.
• All DML happens once, outside the per-record loop.

Business Scenario

Sales leadership doesn't trust the pipeline forecast because reps rarely update ForecastCategoryName manually. A nightly batch should realign it with objective signals: stage, close date, and how long an Opportunity has sat without progressing.

Requirements

• Write RealignForecastCategoryBatch implementing Database.Batchable<SObject>.
• Only process open Opportunities (IsClosed = false).
• An Opportunity is Omitted if its CloseDate has passed, or it has been stalled (no stage change) for at least STALLED_DAYS_THRESHOLD (45) days.
• Otherwise, Closed Won stage maps to Closed; Negotiation/Review or Proposal/Price Quote map to Best Case; anything else keeps its current category.
• Only update Opportunities whose computed category actually differs from the current value.

Best Practices

• Deriving the category from real fields (stage, dates) rather than trusting manual rep input produces a forecast leadership can rely on.
• Comparing against the existing value before adding to toUpdate avoids needless DML rows and preserves field history for genuine changes only.
• All date math and comparisons happen per-record in memory; the only DML is one bulk update outside the loop.

Business Scenario

When an agent goes inactive (leaves the team, is deactivated), their open Cases are orphaned. Support operations needs a batch that reassigns those Cases to active agents who still have spare capacity, instead of a blind round-robin.

Requirements

• Write ReassignCasesToActiveAgentsBatch implementing Database.Batchable<SObject>, Database.Stateful.
• Target only open Cases owned by an inactive agent (Owner.IsActive = false).
• Build each active agent's current open-Case count once (via an aggregate query), and only consider agents under MAX_OPEN_CASES_PER_AGENT (15) as reassignment targets.
• Distribute reassigned Cases across eligible agents rather than dumping them all on one agent, and stop assigning once no eligible agent has spare capacity.

Best Practices

• Basing eligibility on User.IsActive plus a real open-Case count (not just "any active user") prevents dumping work onto an agent who is already overloaded.
• The capacity map is built once via loadAgentCapacity() and reused/mutated in memory across the whole job — no per-record SOQL.
• Database.Stateful keeps casesReassigned (and the capacity map's cumulative state via the cursor) consistent across chunks.
• Bulk DML: exactly one update call per chunk.

Business Scenario

Billing needs one Invoice__c generated per year for every Activated Contract. This runs as a scheduled yearly batch job across the whole Contract population.

Requirements

• Write GenerateYearlyInvoicesBatch implementing Database.Batchable<SObject>, Database.Stateful, tracking how many invoices were created.
• Provide a no-arg constructor (defaults invoiceYear to the current year) and an overloaded constructor accepting an explicit year, for testability and back-filling.
• Only process Contracts with Status = 'Activated'.
• Idempotency: before inserting, check for an existing Invoice__c for the same Contract and year, and skip Contracts that already have one.
• Create Invoice__c with Contract__c, Account__c, Invoice_Year__c, Invoice_Date__c, and Status__c = 'Draft'.

Best Practices

• The idempotency check (querying existing invoices for the chunk's Contract Ids/year before inserting) makes the batch safe to re-run without creating duplicate invoices.
• One query for existing invoices per chunk, one bulk insert — never per-record SOQL or DML.
• Database.Stateful is required to keep invoicesCreated accurate across chunks.

Business Scenario

Finance already loads a nightly extract of ERP account balances into a custom staging object, ERP_Sync_Log__c. This batch performs a purely internal reconciliation — comparing the ERP-side balance already sitting in that object against the corresponding Salesforce Account.AnnualRevenue — and flags mismatches for manual review. There is no external HTTP callout here; the ERP data has already landed.

Requirements

• Write ErpReconciliationBatch implementing Database.Batchable<SObject>, Database.Stateful, counting how many discrepancies were flagged.
• Process only unreconciled ERP_Sync_Log__c records (Reconciled__c = false).
• Compare ERP_Balance__c against the related Account.AnnualRevenue; flag Out_Of_Sync__c = true when the absolute difference exceeds AMOUNT_TOLERANCE (0.01).
• Mark every processed log entry Reconciled__c = true with today's Reconciled_Date__c, regardless of whether it was in sync.

Best Practices

• A small AMOUNT_TOLERANCE constant avoids false-positive discrepancies caused by floating-point/rounding noise.
• Traversing the parent relationship (Account__r.AnnualRevenue) in the same query avoids a second SOQL per chunk.
• Database.Stateful keeps the discrepanciesFlagged total accurate across the whole job for the final summary in finish().
• One bulk update per chunk, wrapped in try/catch(DmlException).

Business Scenario

Every night, an external file-load process drops rows into a staging custom object, Product_Import_Staging__c. Batch Apex cannot itself receive a file, so this batch picks up unprocessed staging rows and upserts them into Product2.

Requirements

• Write ProductCatalogImportBatch implementing Database.Batchable<SObject>, Database.Stateful, tracking created/updated/failed counts.
• Process only unprocessed staging rows (Processed__c = false).
• Rows missing ProductCode__c or Name__c are invalid: mark them processed with an Import_Error__c reason and skip upserting them.
• Match existing Products by ProductCode; use upsert ... ProductCode (upsert on an external-id-like field) to create-or-update in a single DML statement.
• Mark every staging row Processed__c = true once handled, valid or not.

Best Practices

• Looking up existing Products by code with one bulk query (WHERE ProductCode IN :codes) avoids a SOQL call per staging row.
• upsert toUpsert ProductCode; collapses "does this already exist" branching into a single DML statement instead of separate insert/update lists.
• Invalid rows are marked processed (with a reason) rather than left in an infinite retry loop on the next nightly run.
• Database.Stateful keeps the create/update/fail counters accurate for the final finish() summary.

Business Scenario

Loyalty points for enrolled Contacts have drifted from actual purchase history. This batch recalculates every loyalty member's points from their lifetime Activated Order spend, and upgrades their tier once they cross a points threshold.

Requirements

• Write RecalculateLoyaltyPointsBatch implementing Database.Batchable<SObject>, Database.Stateful, counting tier upgrades.
• Only process Contacts flagged Loyalty_Member__c = true.
• Aggregate each Contact's total spend from Activated Orders with a single GROUP BY query per chunk — never per-Contact SOQL.
• Points = spend * POINTS_PER_DOLLAR (2); tier is Platinum once points reach TIER_UPGRADE_THRESHOLD (5000), otherwise Standard.
• Only update Contacts whose points or tier actually changed, and only increment the upgrade counter on a genuine Standard → Platinum transition.

Best Practices

• One aggregate SOQL per chunk keyed by ContactId keeps spend calculation governor-safe regardless of how many Orders exist per Contact.
• Comparing old vs. new points/tier before adding to toUpdate avoids no-op DML on Contacts whose recalculated values didn't change.
• Database.Stateful is required for contactsUpgraded to accumulate correctly across every chunk in the job.

Business Scenario

A high-volume distributor has millions of Order records. Fulfillment status must reflect real shipping progress on the underlying OrderItem lines, but nothing keeps it in sync in real time. This nightly batch recalculates it at scale.

Requirements

• Write OrderFulfillmentStatusBatch implementing Database.Batchable<SObject>, Database.Stateful, counting Orders updated.
• start() must use a narrow, indexed filter (Status IN ('Draft','Activated')) — never a full unfiltered scan of the Order table at this volume.
• Per chunk, aggregate total OrderItem count and shipped OrderItem count per Order with two GROUP BY queries — never per-Order SOQL.
• All items shipped → Activated; some but not all shipped → Draft (partially fulfilled); otherwise leave the status unchanged.

Best Practices

• At multi-million-row scale, the start() filter is what makes the QueryLocator viable at all — an unfiltered query wastes the whole job on records that can never change.
• Two bulk aggregate queries per chunk (total vs. shipped) scale independently of how many line items a single Order has.
• Only updating Orders whose computed status differs from the current one minimizes DML rows across a run touching millions of records.
• Database.Stateful keeps ordersUpdated accurate for the final summary across every chunk.

Business Scenario

Executives want one consolidated Enterprise_Report__c row per sales owner summarizing this year's Closed Won revenue and deal count, aggregated across the entire Opportunity table.

Requirements

• Write EnterpriseReportBatch implementing Database.Batchable<SObject>, Database.Stateful, accumulating per-owner revenue and deal-count totals across every chunk.
• start() filters to Closed Won Opportunities closed in the current reportYear.
• execute() only accumulates in-memory totals into the stateful maps — it must not perform any DML per chunk.
• finish() converts the accumulated maps into one Enterprise_Report__c row per owner and inserts them all in a single bulk DML call.

Best Practices

• Deferring all DML to finish() is correct here because the summary rows depend on totals accumulated across the entire job, not any single chunk.
• Database.Stateful is what allows revenueByRegionOwner and countByRegionOwner to keep accumulating correctly across every execute() call instead of resetting each time.
• The final insert in finish() is still a single bulk DML statement, not one insert per owner.

Business Scenario

A global SaaS company tracks customer subscriptions in a multi-currency org via Subscription__c. Every day, due subscriptions must either auto-renew (advance the renewal date one month) or expire, across every currency and region, with per-record failures isolated so a handful of bad rows never abort the whole run.

Requirements

• Write GlobalSubscriptionRenewalBatch implementing Database.Batchable<SObject>, Database.Stateful, tracking renewed/expired/failed counts.
• Target Active subscriptions whose Renewal_Date__c is due (<= TODAY) — this must work correctly regardless of the org's multi-currency setup.
• A subscription with Auto_Renew__c = true advances Renewal_Date__c by one month and stays Active; otherwise it becomes Expired.
• Validate each subscription has a positive Amount__c before renewing — invalid records must not block the rest of the chunk.
• Use Database.update(toUpdate, false) (partial success) so a DML failure on one record doesn't roll back the whole chunk, and record per-record failures.

Best Practices

• Database.update(list, false) with a per-result check is exactly the pattern for "some records may legitimately fail — keep processing the rest," which matters at global scale where a single bad currency conversion or missing field shouldn't halt the whole batch.
• Validating business rules (positive amount) before attempting DML, via a custom exception, keeps the failure reason meaningful instead of a generic DML error.
• Database.Stateful keeps the renewed/expired/failed counters — and the failure log — accurate across every chunk in the job.
• Currency amounts in a multi-currency org are still ordinary Decimal values on the record; no special handling is needed beyond respecting CurrencyIsoCode when querying/reporting.