Managing the number
Every territory model is right until the account that breaks it.
The Dutch subsidiary of a German group, bought by an American parent, served by the team in Singapore because that is who knows them. No rule will ever produce that answer, and the person who knows it is not going to write one.
So the override has to be permanent, not a note in a field.
Several at once
Many territories, one per axis — so every question still has one answer.
Five kinds: geography, industry, named accounts, company size, and a hybrid. An account can belong to several as long as they are different kinds, so "which region is this" and "which industry team owns this" both have exactly one answer, and neither crowds the other out.
Where two territories of the same kind would both match, the first is kept — chosen the same way every time, so a recalculation never quietly reshuffles what somebody saw yesterday.
- GeographyBeneluxrule
- IndustryLogisticsrule
- Named accountsStrategic — EUpinned by S. Iyer
- A manual pin is structurally safe —
The recalculation filters out anything pinned by hand before deciding what to add or remove. It is not that the rules politely avoid overrides; it is that they never see them.
- Pinning is done where the argument happens —
From the account or the lead itself, not from a settings screen somebody visits twice a year.
- Rules are ordered, first match wins within a territory —
And they are guarded: the expressions they are written in are deliberately limited, so a badly-formed rule cannot consume the machine it runs on.
- The hierarchy refuses loops twice over —
Once in the application and once in the database, so an import cannot create a cycle the interface would have refused.
- Rerunning everything reports what moved —
Accounts and leads swept, assignments added and removed — as four numbers, not a spinner. And one bad record does not stop the sweep.
- A recalculation that changes nothing announces nothing —
No event, no noise. Only actual movement is reported.
What a territory is not
It classifies. It does not assign, and it does not grant access.
This is the thing most likely to be assumed and is worth stating plainly.
A territory does not change who owns an account or a lead. The owner is whatever it was; the territory sits alongside as a classification.
A territory does not widen what anybody can see. Membership is not a visibility grant — access is ownership, team and explicit sharing.
And a territory is not an input to routing. Neither the lead router nor the deal router can test it, so "route Benelux accounts to this team" is expressed as a country rule rather than as a territory rule.
What it is genuinely for: grouping for quotas, reporting on coverage, and giving a name to a set of accounts that somebody owns as a book.
›Do deals belong to territories?
Not directly. Accounts and leads do, and a territory's deal count is derived through the account.
›Can a territory have more than one owner?
A primary owner, which is the one that counts everywhere, and a secondary list that is currently not read by quotas or forecasting. Treat the primary as the answer.
›Can I preview a rule before applying it?
Not today. A rule that is badly formed will simply never match, and nothing surfaces that — so introduce rules one at a time and check what moved after each sweep.
›Can I report on territories?
Not through the report builder; they are not one of its subjects. The territory list carries its own counts.