Skip to content
Namaste Salesforce Namaste Salesforce
Architect Roadmap

Enterprise territory management

When the role hierarchy can’t model your sales coverage, Enterprise Territory Management shares records by territory.

Architect Roadmap Article 1 min

Enterprise Territory Management

The role hierarchy assumes access mirrors a single reporting structure, but many sales organisations do not work that way. A rep might cover accounts by region, by industry, and by product line simultaneously, and an account may be worked by several teams at once. Enterprise Territory Management (ETM) exists for exactly this: it grants record access based on a flexible territory model that sits alongside the role hierarchy rather than being constrained by it.

ETM introduces a few core concepts. A territory model is a complete, versioned definition of your territories that you can build and test in a Planning state before Activating it — and only one model is active at a time, which lets you redesign coverage safely. Within a model, territories form their own hierarchy. Territory types categorise them. Accounts are assigned to territories manually or, powerfully, by assignment rules that match account fields (for example, BillingState or Industry), and users are assigned to territories to gain access to those accounts and their opportunities.

Access flows from these assignments: being a member of a territory grants configurable access (view, edit) to the accounts in it, and territory hierarchies can roll access upward much like the role hierarchy does. Crucially, because a territory model is independent of roles, you can represent multi-dimensional, overlapping coverage that a single role tree cannot.

When to choose ETM over role hierarchy:
  - Coverage is multi-dimensional (geography x segment x product)
  - Accounts are worked by multiple teams simultaneously
  - Assignment should be rule-driven from account attributes
  - You need to model, test, and swap coverage plans without downtime

The trade-off is complexity: ETM adds another sharing mechanism to reason about (and to account for in the "most permissive wins" calculation), its recalculations can be heavy at scale, and forecasting and reporting integrate with it in specific ways. Architects introduce it deliberately, only when the role hierarchy genuinely cannot express the sales coverage.

As an exercise, sketch a two-dimensional coverage model (region by segment), decide the assignment rules that would place accounts automatically, and note how it would combine with your existing OWD. Next we look at restriction rules, which do the opposite job — tightening access rather than granting it.

Advertise with us · 728×90