Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Enterprise Territory Management is a second sharing mechanism that assigns accounts to territories by rule, assigns users to territories, and grants access from that pairing. Its real advantage over the role hierarchy is that it is many-to-many. A user can sit in several territories, an account can belong to several, and neither has to match who reports to whom.

The objects

Territory2Model          a whole plan, with a state
  Territory2             one territory, with a parent
    Territory2Type       a label for territories at a level
    UserTerritory2Association    which users are in it
    ObjectTerritory2Association  which accounts are in it
    ObjectTerritory2AssignmentRule  the criteria that put them there

The model is the unit people underestimate. It has a state of Planning, Active or Archived, and only one is active at a time. So you can build next year’s structure alongside this year’s, run the assignment rules to see which accounts land where, and activate when the plan is agreed. Modelling a reorganisation before committing to it is most of the value here, and it is the part that gets skipped.

Assignment rules

Rules are criteria on Account fields: country, industry, employee count, postcode ranges, custom fields. A rule belongs to a territory and can be marked to apply to child territories too.

Rules run when you activate a model, when you run them manually against a territory, and on account save if the account has the evaluate-against-rules option enabled. That last one is a checkbox, and an account created by an integration without it keeps whatever territories it had, which is usually none.

Accounts can also be assigned manually, and manual assignments survive a rule run. That is the escape hatch for accounts your rules will always get wrong, and it is how a model quietly diverges from its rules over two years. Report on manual assignments occasionally.

The sharing it grants

Territory access is configured per model for accounts, and separately for the opportunities, cases and contacts under those accounts. Each gets a level: no access, view, or view and edit.

The important behaviours:

  • A user in a territory gets the configured access to every account assigned to it.
  • Access rolls up the territory hierarchy. Users in a parent territory see what the children see.
  • It is additive. Territory sharing grants access on top of the role hierarchy and sharing rules. It never takes any away.
  • Opportunity has a Territory2Id field, and opportunity access can be granted from the opportunity’s own territory rather than the account’s, which matters when a deal is worked by someone outside the account’s territory.

Opportunity territory assignment is not rule-driven in the same way. Salesforce runs an Apex class you provide to decide an opportunity’s territory, which means the logic is code and someone has to own it.

When it beats the role hierarchy

The role hierarchy is a single tree and each user occupies one node. Good for approvals and a management chain, bad for anything else. The tell is a role hierarchy containing roles that are not jobs: EMEA Overlay, Named Accounts Shadow, Product Specialist Access.

Territories are the right tool when any of these are true:

  • One account is worked by several people who do not report to each other, such as a named rep plus a product specialist plus a service lead.
  • Coverage is defined by attributes of the account rather than by who owns it, so it should be maintained by rule rather than by hand.
  • The structure changes annually and you need to plan the change before making it.
  • Forecasting should roll up geography rather than the management chain, which territory-based forecasting supports directly.

Stay with the role hierarchy when coverage is ownership plus a manager above it. Territory management adds objects, a model lifecycle, an Apex class and a second place to look when someone cannot see a record. Worth paying for a genuine matrix, dead weight for a simple one.

Debugging access

When a user cannot see an account, check in order: is the user in a territory, is the account in a territory, are they the same one or is one an ancestor, and does the model grant edit at that level. The territory related lists on both records answer the first three.

Frequently asked

Can I have several active models? No, one active at a time. Planning and archived models can coexist with it.

Does activating a model reassign everything? It runs the rules across accounts, which can be a long-running operation on a large org. Do it outside business hours.

Is the old Territory Management the same thing? No, the original feature is a separate and much older implementation. New builds use Enterprise Territory Management.

Do territories affect record ownership? No. Ownership is unchanged. Territories only grant additional access.