Territory Management Architecture

Sales Territories (formerly Enterprise Territory Management) provides a parallel access model to the role hierarchy, enabling account-based territory assignments that drive both sharing and forecasting. At the CTA level, understanding the architecture in depth (object model, hierarchy design, sharing interaction, and scaling limits) separates a passing answer from a failing one.

Name Change - Summer ‘24

Salesforce renamed Enterprise Territory Management (ETM2) to Sales Territories in Summer ‘24 (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.

Figure 1. Territory2Model is the single container for all territory definitions. Territory2Types are classification labels, not hierarchy nodes. The actual hierarchy comes from Territory2.ParentTerritory2Id. Users and accounts connect to territories through separate junction objects, allowing many-to-many assignments.

Territory2 Object Model

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

Figure 2. The Territory2 data model separates structure (Territory2, Territory2Type) from membership (UserTerritory2Association, ObjectTerritory2Association) and automation (ObjectTerritory2AssignmentRule). Understanding these objects is required to query and debug territory assignments via SOQL or the API.

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.

Figure 3. Geographic territory hierarchies group accounts by billing location. Parent territories inherit visibility into child territories, so an Americas manager automatically sees all US West, US Central, and US East accounts without explicit sharing rules.

Pattern 2: Named Account / Segment

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

Figure 4. Named account hierarchies assign strategic accounts to dedicated territories regardless of geography. When combined with geographic territories in a hybrid model, Territory2Type priority determines which territory’s forecast manager receives opportunity credit for accounts that span both.

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 type priorities to match the 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

1. Rules are created with up to 10 filter criteria fields per rule
2. Each rule is associated with one or more territories via RuleTerritory2Association
3. Rules can be inherited by child territories (set IsInherited = true)
4. When rules run, matching accounts get ObjectTerritory2Association records with AssociationCause = 'Rule'
5. 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-Based Sharing

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

How Territory Sharing Works

1. A user is assigned to a territory via UserTerritory2Association
2. An account is assigned to the same territory via ObjectTerritory2Association
3. The user gains access to the account at the level defined in Territory Settings (View Only or View and Edit)
4. 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)

Interaction with Other Sharing Mechanisms

Figure 5. Territory sharing is additive in the sharing stack: a user gains account access when assigned to the same territory as the account, with parent territory users inheriting access to all child territory accounts. This is distinct from and cumulative with role hierarchy and sharing rule access.

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 performance degrades.

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

Figure 6. Only one territory model can be Active at a time. Activating a new model immediately archives the current one and removes its sharing groups, which triggers a full sharing recalculation. For large models this can take hours, requiring maintenance window planning.

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 this mapping is wrong, forecast rollups will be inaccurate. Always align Territory2Type.Priority with the 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.

Related Topics

• 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

Sources

• Salesforce Help: Sales Territories Introduction
• Salesforce Help: Territory Model State
• Salesforce Help: Territory Management 2.0 Data Model
• Salesforce Help: Territory Management Best Practices
• Salesforce Help: Enterprise Territory Management Is Now Sales Territories (Spring ‘25)
• Salesforce Developers: Territory2 Object Reference
• Salesforce Developers: Territory2Model Object Reference
• Salesforce Developers: UserTerritory2Association Object Reference
• Salesforce Developers: ObjectTerritory2Association Object Reference
• Salesforce Developers: Territory Management Data Model Gallery
• Salesforce Implementation Guide: Sales Territories (Spring ‘26 PDF)
• Trailhead: Optimize Performance for Sales Territories
• Trailhead: Effective Sales Forecasting & Territory Management
• Salesforce Ben: Territory Management - 10 Things You Need to Know
• Salesforce Help: Role and Territory Sharing Groups