We recently implemented an automated territory reassignment solution using Apex batch processing that significantly improved our sales coverage and quota attainment. Previously, manual territory assignments were time-consuming and often resulted in gaps in coverage when reps left or territories changed.
Our solution uses automated territory logic that evaluates account attributes, geographic data, and rep capacity in real-time. The Apex batch job runs nightly to reassign accounts based on predefined rules, ensuring optimal distribution. We also integrated quota attainment tracking to monitor performance metrics across territories.
global class TerritoryReassignmentBatch implements Database.Batchable<sObject> {
global Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator('SELECT Id, OwnerId, Territory__c FROM Account WHERE LastModifiedDate = TODAY');
}
}
The results have been impressive - 23% improvement in territory balance and 15% increase in quota attainment within the first quarter. Happy to share implementation details.
We run with batch size of 200 accounts per chunk, executing nightly at 2 AM. For your volume, I’d recommend partitioning by region or account type to avoid timeout issues. We do use Database.Stateful to track reassignment counts and error records across batches. The entire process typically completes in 45-60 minutes for our 180K accounts. One optimization: we filter the query to only process accounts modified in the last 7 days or flagged for review, rather than evaluating the entire database daily. This reduced processing time by 70%.
How are you handling the quota attainment tracking component? Is that part of the same batch job or a separate process? We’re struggling with keeping quota data synchronized when territories change, especially mid-quarter. Would love to understand your approach to maintaining historical accuracy while allowing dynamic reassignments.
Great questions! We used Territory2 model as the foundation but extended it with custom fields for rule parameters. For edge cases, we implemented a Territory_Override__c checkbox on accounts that excludes them from batch processing. The automated territory logic evaluates accounts in priority order: manual overrides first, then strategic accounts (revenue-based), then standard geographic rules. We also built a Territory_Assignment_Log__c custom object to track all changes for audit purposes. The batch respects existing ownership for accounts with active opportunities to avoid disrupting deals in progress.