Sales territories

What it does

A territory is a named grouping of the sales patch — usually geography, sometimes industry or product line — with one manager and a set of member users. Territories can be nested through a parent lookup, and the territory record is referenced from customer records so you can slice pipeline and revenue by patch.

Key facts

Created from Sales Hub under Change area, App Settings, Sales Administration, Sales Territories.
The record has four things that matter: Name, Manager (a single user), Parent (optional, builds the hierarchy) and Description. Members are added from the Related tab.
A user can belong to only one territory. If someone needs to cover a wider patch, the modelled answer is a parent territory above the existing ones, not a second membership.
The manager is a single user lookup, not a team. Co-managed patches need modelling around this.
Hierarchical territory relationships are on by default for new organisations. Older environments that were upgraded may not have it enabled if they already had custom hierarchical relationships on the territory table.
Sub-territories are visible from the Sub-territories tab on the parent record.
Territory is a plain Dataverse lookup on customer records. It does not by itself restrict who can see what — that's security roles, teams and hierarchy security.
The product catalogue setting Allow selection of default pricelist uses territory-based rules to pick a default price list, so territory can drive pricing if you turn that on.
Territory hierarchy is one of the structures forecasting can be built on, which is often the real reason a client wants territories set up properly.

When to use / skip

Set territories up when the business genuinely manages sales by patch and wants to report on it — regional teams, country splits, named-account divisions with a geographic flavour. It is cheap to configure and it gives you a stable dimension for reporting and forecast hierarchies that doesn't depend on the manager chain.

Skip it when the sales organisation is small, or when the only requirement is manager visibility — hierarchy security does that better and needs no ongoing patch maintenance. Skip it too when the client's "territory" concept is really a matrix: patch by geography and by product vertical at the same time. The out-of-the-box model is a single tree with one membership per user, and forcing a matrix into it produces a mess you'll be explaining for years. In that case model the second dimension as a custom table or a set of teams and leave Territory for the primary split.

Configuration decisions

What a territory actually represents for this client — geography, industry, product line or account segment. Pick one dimension.
How deep the hierarchy goes, and whether the top level maps to how the business reports revenue.
Who is territory manager where the patch is genuinely co-managed, and what the fallback is.
Whether territory is set on Account, on Lead and Opportunity, or derived, and whether that's done by hand, by business rule or by an assignment process.
Whether territory drives the default price list, which turns a reporting attribute into something that changes what sellers quote.
Who owns territory changes after go-live, since re-cutting a patch mid-year affects reporting continuity.

Gotchas

One user, one territory. This is the constraint that breaks most designs and it surfaces late, usually when a national account manager needs to appear in three patches.
Adding a territory to a record does not backfill history. Re-cutting territories part-way through a year leaves prior-period pipeline attributed to the old shape unless you plan for it.
Territory membership is not a security boundary. Clients often assume being in a territory limits what a seller sees; it doesn't, and a demo makes that obvious quickly.
Upgraded environments may lack the hierarchical relationship, so the Parent field behaves differently from a fresh environment. Check before you promise a hierarchy.
Deleting or deactivating a territory that's referenced widely leaves lookups pointing at nothing useful and breaks forecast hierarchies built on it.
The manager lookup does not grant that user any access to the territory's records. That has to come from roles or hierarchy security separately.

Consultant notes

Get the client's actual territory map — the spreadsheet the sales ops team really uses — before designing anything. It is almost never as clean as the org chart suggests.
Say early and plainly that a user can only sit in one territory. It reframes the design conversation before you've built anything.
If forecasting is in scope, agree the territory hierarchy first. Rebuilding it after forecasts are live is disruptive.
Load territories as reference data through a solution or a scripted import so dev, test and production stay identical. Hand-keying them in each environment guarantees drift.
Check with the client how often patches change. Annual re-cuts need a documented process, not an admin improvising in production.

Worth another look before each planning cycle, or if the client starts talking about overlay or matrix teams.