Territory Management Architecture

Territory Management (now officially Sales Territories as of Spring ‘25) provides a parallel access model to the role hierarchy, enabling account-based territory assignments that drive both sharing and forecasting. For a CTA, understanding the architecture deeply — object model, hierarchy design, sharing interaction, and scaling limits — separates a passing answer from a failing one.

Name Change — Spring ‘25

Salesforce renamed Enterprise Territory Management (ETM2) to Sales Territories in Spring ‘25 (release 250). The underlying objects, API names, and architecture remain identical. The CTA exam may still reference “Enterprise Territory Management” or “ETM2.” This guide uses “Sales Territories” and “Territory Management” interchangeably.

Architecture Overview

Sales Territories introduces a territory hierarchy that operates independently of — and in parallel with — the role hierarchy. Users can belong to multiple territories (unlike roles, which are one-per-user), and accounts can be assigned to multiple territories simultaneously.

flowchart TD
    subgraph "Territory Management Architecture"
        direction TB
        Model["Territory2Model\n(Container for entire model)"]
        Model --> Type1["Territory2Type\n'Geographic'"]
        Model --> Type2["Territory2Type\n'Named Account'"]
        Model --> Type3["Territory2Type\n'Industry Vertical'"]

        Type1 -.->|categorizes| T1["Territory2\n'Americas'"]
        T1 --> T2["Territory2\n'US West'"]
        T1 --> T3["Territory2\n'US East'"]
        T1 --> T4["Territory2\n'LATAM'"]

        Type2 -.->|categorizes| T5["Territory2\n'Strategic Accounts'"]
        T5 --> T6["Territory2\n'Enterprise Named'"]

        T2 --- UTA1["UserTerritory2Association\n(User ↔ Territory)"]
        T2 --- OTA1["ObjectTerritory2Association\n(Account ↔ Territory)"]
        T2 --- Rules["Assignment Rules\n(Auto-assign accounts)"]
    end

    style Model fill:#1565c0,color:#fff
    style Type1 fill:#1976d2,color:#fff
    style Type2 fill:#1976d2,color:#fff
    style Type3 fill:#1976d2,color:#fff
    style T1 fill:#2e7d32,color:#fff
    style T5 fill:#2e7d32,color:#fff

Territory2 Object Model

The data model centers on six core objects. Understanding their relationships is essential for CTA-level territory design.

erDiagram
    Territory2Model ||--o{ Territory2 : contains
    Territory2Model ||--o{ Territory2Type : defines
    Territory2Type ||--o{ Territory2 : categorizes
    Territory2 ||--o{ Territory2 : "parent-child"
    Territory2 ||--o{ UserTerritory2Association : "assigns users"
    Territory2 ||--o{ ObjectTerritory2Association : "assigns records"
    Territory2Model ||--o{ ObjectTerritory2AssignmentRule : "defines rules"
    ObjectTerritory2AssignmentRule ||--o{ ObjectTerritory2AssignmentRuleItem : "has criteria"
    ObjectTerritory2AssignmentRule ||--o{ RuleTerritory2Association : "maps to territories"

Object Reference

Object	Purpose	Key Fields
Territory2Model	Top-level container; represents the entire territory structure	`Name`, `State` (Planning/Active/Archived), `ActivatedDate`
Territory2	Individual territory node in the hierarchy	`Name`, `Territory2ModelId`, `Territory2TypeId`, `ParentTerritory2Id`, `ForecastUserId`
Territory2Type	Classification label for territories (not hierarchical)	`Name`, `Priority`, `Description`
UserTerritory2Association	Junction: assigns a user to a territory	`Territory2Id`, `UserId`, `IsActive`, `RoleInTerritory2`
ObjectTerritory2Association	Junction: assigns a record (Account, Lead, or Case) to a territory	`Territory2Id`, `ObjectId`, `AssociationCause` (Rule/Manual/Owner)
ObjectTerritory2AssignmentRule	Rule definition for auto-assigning records	`Territory2ModelId`, `BooleanFilter`, `IsActive`, `IsInherited`
ObjectTerritory2AssignmentRuleItem	Individual criterion within a rule	`RuleId`, `Field`, `Operation`, `Value`
RuleTerritory2Association	Maps a rule to the territories it assigns into	`RuleId`, `Territory2Id`, `IsInherited`

CTA Data Model Insight

Territory2Type is not hierarchical — it is purely a label/classification. The hierarchy comes from Territory2.ParentTerritory2Id. This is a common misunderstanding. Types categorize territories (e.g., “Geographic,” “Named Account”) and carry a Priority field used for opportunity territory assignment when an account belongs to multiple territories.

Territory Hierarchy Design Patterns

Pattern 1: Geographic

Best for field sales organizations where territory boundaries align to regions.

flowchart TD
    Global["Global"] --> AMER["Americas"]
    Global --> EMEA["EMEA"]
    Global --> APAC["APAC"]
    AMER --> US["United States"]
    AMER --> CAN["Canada"]
    AMER --> LATAM["LATAM"]
    US --> West["US West\n(CA, OR, WA, NV)"]
    US --> Central["US Central\n(TX, IL, CO, MN)"]
    US --> East["US East\n(NY, MA, FL, GA)"]

    style Global fill:#1565c0,color:#fff
    style AMER fill:#1976d2,color:#fff
    style EMEA fill:#1976d2,color:#fff
    style APAC fill:#1976d2,color:#fff

Pattern 2: Named Account / Segment

Best for organizations where strategic accounts are carved out regardless of geography.

flowchart TD
    All["All Territories"] --> Strat["Strategic\n(Top 50 accounts)"]
    All --> Ent["Enterprise\n($10M+ revenue)"]
    All --> MM["Mid-Market\n($1M-$10M)"]
    All --> SMB["SMB\n(< $1M)"]
    Strat --> S1["Named: Acme Corp"]
    Strat --> S2["Named: GlobalTech"]
    Ent --> E1["Enterprise West"]
    Ent --> E2["Enterprise East"]

    style All fill:#1565c0,color:#fff
    style Strat fill:#c62828,color:#fff
    style Ent fill:#e65100,color:#fff

Pattern 3: Hybrid (Most Common in CTA Scenarios)

Combines geographic and named-account patterns using Territory2Types.

Territory2Type	Priority	Assignment Logic	Example
Named Account	1 (highest)	Manual assignment; specific reps own named accounts	”Acme Corp” always goes to Rep A
Industry Vertical	2	Criteria-based: `Industry = 'Healthcare'`	All healthcare accounts to vertical team
Geographic	3 (lowest)	Criteria-based: `BillingState IN (...)`	Catch-all by region

Priority for Opportunity Assignment

When an account belongs to multiple territories, the Territory2Type.Priority field determines which territory’s forecast manager gets credit for the opportunity. Lower priority number = higher precedence. Design your type priorities to match your compensation model.

Assignment Rules

Assignment rules automate account-to-territory placement based on field criteria. Rules are defined at the model level and mapped to specific territories.

How Assignment Rules Work

Rules are created with up to 10 filter criteria fields per rule
Each rule is associated with one or more territories via RuleTerritory2Association
Rules can be inherited by child territories (set IsInherited = true)
When rules run, matching accounts get ObjectTerritory2Association records with AssociationCause = 'Rule'
Manually assigned accounts (AssociationCause = 'Manual') are not overwritten by rules

Assignment Rule Evaluation

Aspect	Behavior
Trigger	Run manually from Setup, or on account create/update if configured
Criteria fields	Up to 10 per rule; use formula fields to combine criteria if more needed
Boolean filter	Supports AND/OR logic between criteria items
Inheritance	Parent rules can cascade to child territories automatically
Evaluation order	Child territories evaluated before parents in the hierarchy
Conflict resolution	An account can match multiple rules and belong to multiple territories — this is by design

The 10-Field Limit

Assignment rules support a maximum of 10 filter criteria fields. For complex segmentation, create formula fields that combine multiple fields into a single evaluable value. Example: concatenate BillingCountry + BillingState into a Territory_Key__c formula field.

Rule vs Manual Assignment

Method	When to Use	Survives Rule Re-run?
Rule-based	Accounts follow predictable patterns (geography, revenue, industry)	Recalculated on each run
Manual	Strategic/named accounts that must stay with specific reps	Yes — manual assignments persist
API-based	Bulk loading territory assignments from external systems (e.g., HR/comp systems)	Depends on `AssociationCause`

Territory membership grants record access through the sharing engine. This operates in parallel with — and additive to — OWD, role hierarchy, and sharing rules.

A user is assigned to a territory via UserTerritory2Association
An account is assigned to the same territory via ObjectTerritory2Association
The user gains access to the account at the level defined in Territory Settings (View Only or View and Edit)
Access is inherited upward in the territory hierarchy — users in parent territories see accounts in child territories

Territory Access Levels

Setting	Users See	Users Edit	Configured In
View Only	All accounts in their territory + child territories	Only own records	Territory Settings (per object)
View and Edit	All accounts in their territory + child territories	All accounts in their territory + child territories	Territory Settings (per object)

flowchart LR
    subgraph "Access Is Cumulative"
        OWD["OWD\n(Baseline)"] --> RH["Role Hierarchy\n(Upward visibility)"]
        RH --> SR["Sharing Rules\n(Criteria/ownership)"]
        SR --> TM["Territory Membership\n(Territory-based access)"]
        TM --> Teams["Teams / Manual\n/ Apex Sharing"]
    end

    subgraph "Territory Sharing Detail"
        UserAssign["User assigned to\nTerritory 'US West'"]
        AcctAssign["Account assigned to\nTerritory 'US West'"]
        UserAssign --> Grant["User gets View or\nView+Edit on Account"]
        AcctAssign --> Grant
        ParentUser["User in parent\n'Americas'"] --> Inherit["Inherits access to\n'US West' accounts"]
    end

    style TM fill:#2e7d32,color:#fff
    style Grant fill:#2e7d32,color:#fff

Territory Sharing Groups

Salesforce creates internal sharing groups for each territory (e.g., Territory2_USWest). These groups are used in the object share tables (AccountShare) to grant access. Large territory models with thousands of territories create thousands of sharing groups, which increases sharing recalculation time. Monitor the Group and GroupMember tables if you see performance degradation.

Territory Management vs Role Hierarchy

This is a core CTA architectural decision. They are complementary, not competing mechanisms.

Detailed Comparison

Dimension	Role Hierarchy	Territory Management
Primary purpose	Management visibility; approval routing	Sales territory alignment; account coverage
Users per group	One role per user	Multiple territories per user
Records per group	Record ownership (1 owner)	Multiple territories per account
Hierarchy depth	Keep to 5-7 levels for performance	Flexible; depth limited by territory count
Sharing direction	Upward (managers see subordinate records)	Upward (parent territory sees child accounts)
Forecasting	Standard role-based forecasting	Territory-based forecasting (independent)
Assignment method	Manual (user profile)	Rules-based + manual
Coexistence	Always present	Optional; runs alongside role hierarchy
Performance cost	Standard sharing calculation	Additional sharing groups + calculations
Reporting	Standard report types	Territory-specific report types

Decision Guide: When to Use Each

Signal in CTA Scenario	Recommendation
”Sales reps cover multiple regions”	Territory Management — users need multiple territory assignments
”Accounts should be visible to all reps in a region”	Territory Management — territory-based sharing
”Forecast by territory, not manager”	Territory Management — territory forecasting
”Simple reporting structure, one manager per team”	Role hierarchy alone is sufficient
”Matrix organization with dual reporting”	Territory Management supplements the flat role hierarchy
”Overlapping sales coverage (overlay reps)“	Territory Management — accounts in multiple territories
”Account assignment changes frequently by geography”	Territory Management — assignment rules automate realignment

They Coexist — Always

You never replace the role hierarchy with territory management. The role hierarchy handles management visibility, approvals, and standard forecasting. Territory management handles sales coverage, territory-based sharing, and territory forecasting. Design both, explain both on the CTA board.

Model Lifecycle

Territory models move through three states. Only one model can be Active at a time.

State	Purpose	What Happens	Can Edit?
Planning	Build and test the territory structure	No sharing rules applied; no account access granted	Yes — full editing
Active	Live model driving sharing and forecasting	Sharing groups created; territory access enforced; forecast enabled	Yes — changes apply immediately
Archived	Preserved for reference; no longer driving access	All sharing from this model removed; territory data preserved	No — read only

Model Limits by Edition

Edition	Max Models (Total)	Max Active Models	Max Territories
Enterprise	2	1	1,000
Developer / Performance / Unlimited	4	1	1,000 default (expandable to 20,000 via Support, up to 99,999 with special approval)

Activation and Transition Flow

stateDiagram-v2
    [*] --> Planning : Create new model
    Planning --> Active : Activate\n(creates sharing groups,\nenforces access)
    Active --> Planning : Clone to new model\nfor restructuring
    Active --> Archived : Archive\n(removes all territory sharing)
    Archived --> [*] : Delete (optional)

    note right of Active : Only 1 active model\nat a time. Activating\na new model archives\nthe current one.

Activation Is Not Instant

Activating a territory model triggers sharing recalculation for all territory-to-account-to-user combinations. For large models (thousands of territories, tens of thousands of accounts), activation can take hours. Plan activations during maintenance windows. Monitor the Territory2AlignmentLog object for completion status.

Territory Forecasting Integration

Territory-based forecasting runs independently of role-hierarchy-based forecasting and uses the territory hierarchy to roll up opportunity amounts.

Aspect	Role-Based Forecast	Territory-Based Forecast
Hierarchy used	Role hierarchy	Territory hierarchy
Forecast manager	User’s manager in role hierarchy	`Territory2.ForecastUserId` per territory
Opportunity rollup	By opportunity owner’s role	By account’s territory assignment
Multi-territory accounts	N/A	Opportunity rolls up to one territory only (based on `Territory2Type.Priority`)
Requires	Collaborative Forecasting enabled	Sales Territories enabled + Collaborative Forecasting

Opportunity-to-Territory Assignment

When an account belongs to multiple territories, the opportunity is assigned to the territory whose Territory2Type has the lowest priority number (highest precedence). If you get this wrong, forecast rollups will be inaccurate. Always align Territory2Type.Priority with your compensation and forecasting model.

CTA Scenario Patterns

Scenario 1: Multi-Region Sales Organization

Situation: A company has 500 sales reps across North America, EMEA, and APAC. Reps cover geographic regions, but 30 strategic account managers cover named accounts globally. Forecasting must reflect territory performance, not individual rep performance.

Architecture:

Territory model with two Territory2Types: “Named Account” (Priority 1) and “Geographic” (Priority 2)
Geographic hierarchy: Global > Region > Country > State/Province
Named accounts manually assigned to Strategic Account territories
All other accounts auto-assigned via rules using BillingCountry + BillingState
Territory-based forecasting with forecast managers at the region level
Role hierarchy kept flat (3 levels) for management approval routing only

Scenario 2: Overlay Sales Model

Situation: A SaaS company has both direct reps and product specialist overlays. The same account may need visibility from the regional rep, the product specialist, and the strategic account manager.

Architecture:

Account assigned to multiple territories simultaneously (this is the key differentiator vs role hierarchy)
Territory types: “Direct Sales” (Priority 1), “Product Overlay” (Priority 2), “Service” (Priority 3)
Direct reps get View and Edit; overlay reps get View Only
Opportunity forecast rolls up through the Direct Sales territory (Priority 1)
Role hierarchy handles management visibility for each team independently

Scenario 3: Multi-BU Organization with Shared Accounts

Situation: A conglomerate has three business units sharing one Salesforce org. Each BU has its own sales team but some enterprise accounts buy from multiple BUs.

Architecture:

Single territory model with BU-level top territories (BU1, BU2, BU3)
Each BU branch has its own geographic sub-territories
Shared accounts assigned to territories in each relevant BU
Territory type priorities set so each BU’s forecast is independent
Consider supplementing with Account Teams for cross-BU collaboration on specific deals

Performance and Scaling Considerations

Metric	Guideline	Risk if Exceeded
Territories per model	1,000 (EE) / 99,999 (UE)	Hard limit; cannot exceed
Accounts per territory	Keep under 10,000	Performance degradation in sharing calculations
Users per territory	Use API for >1,500 users	Setup UI times out; API required
User-to-territory ratio	~3 territories per user (rule of thumb)	Excessive sharing group memberships
Assignment rule criteria	Max 10 fields per rule	Use formula fields to combine criteria
Sharing recalculation	Proportional to territories x accounts x users	Schedule activations in maintenance windows

Sharing Group Explosion

Each territory creates internal sharing groups. For a model with 5,000 territories and 10,000 users, this can produce millions of GroupMember records. This directly impacts: (1) sharing recalculation time, (2) SOQL query performance on shared records, (3) group membership computation time. For very large models, consider flattening the hierarchy and using criteria-based sharing rules to supplement.

Common Gotchas

Only One Active Model

You can have multiple models in Planning state, but only one model can be Active at a time. Activating a new model automatically archives the current active model. There is no way to have two models driving sharing simultaneously. If you need separate territory structures for Sales and Service, build them as branches within one model.

Original Territory Management Is Retired

The original Territory Management (TM1) is a legacy feature. Salesforce no longer supports new enablement. If a CTA scenario mentions “Territory Management,” assume Sales Territories (ETM2/TM2) unless explicitly stated otherwise. Migration from TM1 to TM2 requires re-implementation — there is no automated migration path.

Custom Object Support

By default, territory assignment rules support Accounts and (since recent releases) Leads. Custom objects are not directly supported by territory assignment rules. To extend territory-based sharing to custom objects, use Apex triggers or sharing rules that reference territory-related fields.

Sharing Model: OWD, Role Hierarchy & Sharing Rules — territory management as part of the sharing stack
Security Decision Guides — flowcharts for choosing sharing mechanisms
System Architecture — org strategy and multi-BU considerations
Security Trade-offs — territory complexity vs sharing performance
Data Architecture — LDV impact on territory sharing calculations

Territory Management Architecture

Architecture Overview

Territory2 Object Model

Object Reference

Territory Hierarchy Design Patterns

Pattern 1: Geographic

Pattern 2: Named Account / Segment

Pattern 3: Hybrid (Most Common in CTA Scenarios)

Assignment Rules

How Assignment Rules Work

Assignment Rule Evaluation

Rule vs Manual Assignment

Territory-Based Sharing

How Territory Sharing Works

Territory Access Levels

Interaction with Other Sharing Mechanisms

Territory Management vs Role Hierarchy

Detailed Comparison

Decision Guide: When to Use Each

Model Lifecycle

Model Limits by Edition

Activation and Transition Flow

Territory Forecasting Integration

CTA Scenario Patterns

Scenario 1: Multi-Region Sales Organization

Scenario 2: Overlay Sales Model

Scenario 3: Multi-BU Organization with Shared Accounts

Performance and Scaling Considerations

Common Gotchas

Related Topics

Sources