Territory Administration: Role, Process, and Best Practices

A practical guide for operators responsible for territory administration, with the decisions, evidence, controls, examples, and operating rules needed to make it work.

By George James, Co-Founder & CPO

Territory management is the ongoing job after launch. It is not the design project, not a realignment, and not lead routing. That position is useful only when the planning team can translate it into inputs, decisions, controls, and a result the field can understand.

BoogieBoard treats territory administration as part of a governed change process. The model must connect market strategy with account-level evidence, productive capacity, explicit decision rights, and controlled activation. The objective is not to remove judgment. It is to make judgment visible and repeatable.

The central position is: The territory is the durable unit, not the rep. The sections below turn that position into definitions, alternatives, procedures, examples, controls, and an operating decision.

Working Definitions

• Territory Management: the ongoing maintenance of an approved territory model without redesigning its core logic.
• territory-based model: a coverage model in which the territory persists while people rotate through assigned roles.
• Forecast Manager: the user designated to own the forecast rollup for a territory in Salesforce.
• orphan window: the period when a durable territory or role lacks its permanent assignee.
• Territory2: the Salesforce object representing an individual territory in an Enterprise Territory Management model.

The framework reflects BoogieBoard's consulting work and interviews with more than 300 companies. It is practitioner evidence used to form hypotheses, not a controlled causal study. For territory administration, use that observation only for the claim and population it directly supports.

Independent evidence provides a separate check for territory administration: Salesforce's platform-sharing architecture separates frequent territory-membership changes from less frequent hierarchy realignments and treats the territory hierarchy as distinct from the role hierarchy.

A Practical Decision Lens: Territory Administration

Administration fails when ordinary hiring, departure, data, and customer events are treated as design projects, because the model never becomes durable enough to operate or measure. A practical test is to pick one surprising account and trace it end to end. Explain why it is in the segment, why it belongs in the territory, whether it is locked, which goals it affects, and what happens when the seller changes. If the answer requires several private spreadsheets, the model is not yet governed. In territory administration, test the choice against territory-based model, then record any accepted exception in the decision log.

territory-based model: The Decision Test

Frequent local intervention can resolve today's complaint, while stable administration protects continuity; the operating cadence must fix genuine exceptions without converting manager preference into permanent territory logic. Use this module to make the hidden decision explicit. State the role, population, evidence, rule, exception path, and operating consequence. The objective is not a perfectly clean model; it is a model whose compromises are visible enough to approve, communicate, and improve. The territory administration review is complete only when Forecast Manager and the affected account roster tell the same story.

Territory Management: The Decision Test

For Territory Management: The Decision Test, hold definitions constant while comparing the tradeoff. Use orphan window to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Operating and Governing the Model: Territory Administration

Give RevOps process and system stewardship, give Sales leaders business accountability, review unassigned accounts and vacancies on a regular cadence, route exceptions through published decision rights, and reserve redesign for structural evidence. Governance begins with decision rights and a source-of-truth map. Sales leadership owns strategy and quota choices; RevOps owns configuration, data quality, workflow, and activation. Managers contribute field evidence, while the named Approver resolves exceptions before the effective date. For territory administration, name the approver, the permitted evidence, and the condition that would justify a departure from the rule.

territory-based model: The Decision Test: Review 5

For territory-based model: The Decision Test: Review 5, assign decision rights, review cadence, and correction path. Use Territory Management to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Forecast Manager: The Decision Test

For Forecast Manager: The Decision Test, make the implicit policy inspectable at account level. Use territory-based model to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

orphan window: The Decision Test

For orphan window: The Decision Test, make the implicit policy inspectable at account level. Use orphan window to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Territory2: The Decision Test

For Territory2: The Decision Test, make the implicit policy inspectable at account level. Use Territory2 to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Systems and Tooling: Territory Administration

Technology should preserve territory structure, role assignments, scenarios, approvals, effective dates, and account-level change history, not merely update an Owner field. Test how Territory Management, territory-based model, and Forecast Manager behave from source data through review and Salesforce activation. The territory administration review is complete only when Forecast Manager and the affected account roster tell the same story.

Forecast Manager: The Decision Test: Review 11

For Forecast Manager: The Decision Test: Review 11, assign decision rights, review cadence, and correction path. Use territory-based model to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

See Territory Management in the Planning Workflow

The relevant product workflow is Sales Manager Territory Review. BoogieBoard Scenario Planning keeps the account-level assumptions, tradeoffs, and proposed assignments visible while the team completes that work.

A manager can review mapped coverage and territory measures before requesting or approving changes.

territory-based model: The Decision Test: Review 12

For territory-based model: The Decision Test: Review 12, trace the change from source data through Salesforce activation. Use Forecast Manager to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Advanced Considerations: Territory Administration

Use this module to make the hidden decision explicit. State the role, population, evidence, rule, exception path, and operating consequence. The objective is not a perfectly clean model; it is a model whose compromises are visible enough to approve, communicate, and improve. Give the territory administration decision a source date, an owner, and a condition that would trigger revision.

territory-based model: The Decision Test 2

For territory-based model: The Decision Test 2, make the implicit policy inspectable at account level. Use Territory Management to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

territory-based model: The Decision Test: Review 16

For territory-based model: The Decision Test: Review 16, hold definitions constant while comparing the tradeoff. Use territory-based model to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Inputs and Assumptions 2: Territory Administration

A practical test is to pick one surprising account and trace it end to end. Explain why it is in the segment, why it belongs in the territory, whether it is locked, which goals it affects, and what happens when the seller changes. If the answer requires several private spreadsheets, the model is not yet governed. In territory administration, test the choice against territory-based model, then record any accepted exception in the decision log.

orphan window: The Decision Test 2

For orphan window: The Decision Test 2, make the implicit policy inspectable at account level. Use orphan window to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Territory2: The Decision Test 2

For Territory2: The Decision Test 2, make the implicit policy inspectable at account level. Use Territory2 to test whether the live state, future scenario, and approved Salesforce result remain consistent; record exceptions instead of hiding them in a person field.

Practical Implications

Territory administration is the recurring work that keeps an approved model accurate after launch: assignments, vacancies, temporary coverage, exceptions, data corrections, forecast roles, and controlled changes.

A seller departure should open an orphan window with temporary coverage and a dated replacement plan inside the existing Territory2 rather than triggering an immediate boundary redesign.

Decision Worksheet

Decision	Evidence to inspect	Control
Define the population	Territory Management and comparable roles	Named data owner
Measure the current state	territory-based model and Forecast Manager	Source date and baseline
Choose the tradeoff	Scenario comparison and complete Territory Health	Recorded approver
Activate the result	Account roster, changes, quota, and transition rules	Effective date and correction path

Source of Truth and Identity Controls

Create a field-level source map for territory administration. Name the authoritative system for account identity, hierarchy, segment, owner, territory, role, opportunity, and customer obligation. Reconcile records with a stable external ID, flag unmatched accounts, and prevent a local spreadsheet or custom person field from quietly becoming another golden record. Use Territory Management as the account-level test for this control.

Current-to-Future Scenario Test

Preserve the live Salesforce configuration as a dated Current State Scenario before evaluating territory administration. Build the proposed model separately, compare every changed account and role, and keep rejected alternatives available. Reviewers should see both the summary tradeoff and the exact records behind it. For territory-based model, record the assumption that would cause the future state to change.

Approval and Exception Review

Classify feedback on territory administration as a data correction, policy exception, or preference. Corrections update governed evidence; exceptions require a reason, owner, and expiry or review condition; preferences remain visible without silently changing the model. Name one Approver and use Forecast Manager to show which evidence that person considered.

Salesforce Activation Checklist

Turn the approved territory administration scenario into a deployment package containing territory and role changes, account identifiers, effective dates, exceptions, and rollback instructions. Sync only approved records, capture failures, and compare the activated Salesforce state with the package. Close the change only when orphan window and the affected account roster reconcile.

Monitoring and Change Triggers

Monitor territory administration through defined triggers: unmatched or unassigned accounts, role vacancies, stale source data, expired exceptions, failed syncs, and material differences between the approved and live states. Use Territory2 to decide whether the event is routine maintenance or evidence that the model itself needs redesign.

Account-Level Reconciliation

Select a sample of changed, unchanged, locked, customer, prospect, parent, and subsidiary accounts from territory administration. Trace each record from governed source data through the scenario, approval, and Salesforce result. Investigate any case where Territory Management, the role assignment, and the documented reason do not tell the same story.

Source of Truth and Identity Controls: Extended Review 2

Create a field-level source map for territory administration. Name the authoritative system for account identity, hierarchy, segment, owner, territory, role, opportunity, and customer obligation. Reconcile records with a stable external ID, flag unmatched accounts, and prevent a local spreadsheet or custom person field from quietly becoming another golden record. Use territory-based model as the account-level test for this control.

Current-to-Future Scenario Test: Extended Review 2

Preserve the live Salesforce configuration as a dated Current State Scenario before evaluating territory administration. Build the proposed model separately, compare every changed account and role, and keep rejected alternatives available. Reviewers should see both the summary tradeoff and the exact records behind it. For Forecast Manager, record the assumption that would cause the future state to change.

Frequently Asked Questions

Who owns territory administration, RevOps or Sales?

Territory administration is the recurring work that keeps an approved model accurate after launch: assignments, vacancies, temporary coverage, exceptions, data corrections, forecast roles, and controlled changes. Frequent local intervention can resolve today's complaint, while stable administration protects continuity; the operating cadence must fix genuine exceptions without converting manager preference into permanent territory logic. Use the published definitions and complete-territory result instead of relying on one universal benchmark.

How often should territories be reviewed?

Give RevOps process and system stewardship, give Sales leaders business accountability, review unassigned accounts and vacancies on a regular cadence, route exceptions through published decision rights, and reserve redesign for structural evidence. A seller departure should open an orphan window with temporary coverage and a dated replacement plan inside the existing Territory2 rather than triggering an immediate boundary redesign. Publish the assumptions so another reviewer can reproduce the answer.

What data is required for territory administration?

For territory administration, assemble governed account data, current assignments, role capacity, and decision evidence for Territory Management, territory-based model, and Forecast Manager. Date the sources and publish the definitions so another reviewer can reproduce the result and separate a factual correction from a policy exception.

How often should territory administration be reviewed?

Review territory administration on the formal planning cadence and whenever the inputs behind Territory Management, territory-based model, and Forecast Manager change materially. Keep customer and pipeline ownership stable between reviews; reopen the model when strategy or new evidence changes the decision, not merely because a manager prefers a different assignment.

How should Salesforce and the planning layer divide responsibility?

For territories, keep the governed source data behind Territory Management, territory-based model, and Forecast Manager in its approved system, compare current and future states in the planning layer, and operate only approved assignments in Salesforce. Stable identifiers, field ownership, and a dated sync prevent competing records of truth.

How should territory changes be tested before activation?

Changes to territories should be tested by freezing the live Salesforce state, validating the inputs behind Territory Management, territory-based model, and Forecast Manager, modeling the proposed future scenario, inspecting account-level differences and exceptions, and recording approval. Activate on a defined date and reconcile the deployed result to the approved scenario.

In Summary

Territory management is the ongoing job after launch. It is not the design project, not a realignment, and not lead routing. Use the sequence above to keep the decision governed, evidence-based, and inspectable at both the account and territory levels.

See Territory Planning in Practice

Related Content

• Salesforce Territory Tracking: Complete 2026 Guide
• Designing Books of Business: The Complete Guide
• How to Communicate a New Territory Plan Effectively

Schedule a Live Demo to model territory administration, compare scenarios, and make the account-level tradeoffs visible before activation.