What It Does

Enterprise Territory Management (ETM) lets you organize sales users into geographic, industry, or account-based territories, then control which Accounts each territory owns. Users get access to Accounts via territory assignment, not via direct record ownership.

The result: a sales rep’s quota territory, their Account access, and their visibility in reports are all driven by one territory model.

The alternative — role hierarchies and manual sharing rules — works for small orgs and breaks at enterprise scale. ETM is the tool for sales orgs with hundreds of reps and dynamic territory changes.

When You Need It

You need ETM when:

  • Sales reps’ books change based on geography, industry, or account tier.
  • You have hundreds of reps and complex coverage rules.
  • Reps share accounts (multiple reps own different slices of the same account).
  • Territory changes happen quarterly or more often.

You don’t need ETM when:

  • Reps own their accounts directly and rarely change.
  • Your sharing needs are covered by a role hierarchy.
  • You have fewer than 50 sales users.

ETM has real operational overhead. Don’t adopt it without a clear pain point.

Core Concepts

Territory Type

Defines the category — “Geographic,” “Industry,” “Named Account.” Territory Types group Territories with similar purposes.

Territory

A specific assignment — “West Region,” “Healthcare Vertical,” “Named Accounts - Tier 1.” Territories have hierarchy; a parent territory rolls up its children.

Territory Model

A versioned set of territories. You can have an active model and several inactive “planning” models. Switch models at once during a realignment.

Territory Assignment Rule

An automated rule that assigns Accounts to Territories based on criteria — “Accounts in the US West states go to West Region.”

User Assignment

Users belong to Territories. One user can belong to multiple. A user’s access includes all Accounts assigned to any Territory they’re part of.

The Territory Model

The model is the root metadata. Create a new model in Setup → Territories → Territory Models. Give it a name, pick a description, save.

Models have states:

  • Planning: editable, not yet affecting user access.
  • Active: in effect — users have access based on this model.
  • Archived: historical.

Only one model can be Active at a time. You typically build the next model in Planning state, test it, then switch.

Hierarchy

Territories nest: West Region > California > SF Bay. Parent territories implicitly include child territory access (via forecast rollup and record visibility settings).

Hierarchy depth is capped (10 levels historically). Most orgs use 3–4 levels.

Assignment Rules

Account assignment rules evaluate Account fields:

  • State/Country (for geographic territories).
  • Industry (for vertical territories).
  • Account Owner (for named-account territories).
  • Custom fields.

Rules can be:

  • Assignment rules applied on create/edit — evaluated on save.
  • Run rules now — manual invocation after bulk data change.

Rules fire in a defined order; Accounts can match multiple territories and be assigned to all that match, unless constrained.

Access Model

A user in a territory gets default access to that territory’s Accounts — Read, Read/Write, or Read/Write/Transfer. Default access applies to the Account itself and (optionally) to related Contacts and Opportunities.

For specific Accounts requiring different access, use manual sharing or criteria-based sharing rules on top.

Running ETM at Scale

Model planning discipline. Build a Planning model, run rules, review assignments, fix edge cases, activate. Don’t edit Active models directly.

Change windows. Realignments should happen on known dates, communicated in advance. Users lose visibility or gain it at activation — no silent shifts.

Reassignment flows. When an Account is reassigned, related Opportunities and Contacts may need coordination. Build post-reassignment flows to keep forecasts coherent.

Audit trails. Keep records of model activations — when, who, why. At scale, “why does this rep have this account?” becomes a frequent question.

Common Pitfalls

Too many territories. A thousand territories become a forest. Stick to meaningful buckets.

Over-reliance on default access. If most reps need more than default access, the model is under-configured. Add manual shares or sharing rules.

Forgetting Contact and Opportunity access. Default access can cascade to Contacts and Opportunities, but it isn’t automatic — configure each.

Orphaned accounts. When an assignment rule doesn’t match, an account has no territory. Build catchall territories or sweep processes.

Skipping tests in Planning. Activating a model that hasn’t been tested leads to sudden access loss reported by every rep at once.

Migration From Legacy Territory Management

Salesforce’s original “Territory Management” feature (without “Enterprise”) is deprecated. ETM is the supported path.

Migration is non-trivial — documented by Salesforce. Key steps:

  1. Enable ETM (cannot coexist with legacy TM).
  2. Rebuild territories in the ETM model.
  3. Map users and accounts.
  4. Test access.
  5. Activate.

Expect weeks to months depending on complexity.

Integration With Other Features

Forecasting. ETM is a prerequisite for many forecast patterns. Territories become the forecast hierarchy.

Salesforce Maps / Territory Planning. An add-on that plans territories via drag-and-drop on a map.

Sales Cloud reports. Territory-based reporting groups data by territory hierarchy.

Permissions. Admins managing territories need the “Manage Territories” permission. Granting broadly exposes sensitive operations.

Frequently Asked Questions

Can a user belong to multiple territories?

Yes. Their access is the union of all assigned territories.

Can an Account belong to multiple territories?

Yes — supports shared account coverage models.

How does ETM interact with sharing rules?

Sharing rules layer on top of territory access. You can extend access but not restrict territory-granted access with sharing rules.

Is there an API?

Yes. Territories, rules, and assignments are accessible via SOAP and REST APIs. Useful for bulk model updates during realignment.

Share