Skip to content
SteveTechArcSteveTechArc Courses

Territories and Roles Together

Module 4 of 6 in the chapter Config-Based Sharing: Manual Shares, Teams and Territories, chapter 9 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When an org has both a role hierarchy and a territory hierarchy, who sees an account, and how do you keep the two from fighting each other?

Turn on territories, and you don’t swap one hierarchy for another. You run two. Salesforce’s architects say it plainly: “If Enterprise Territory Management is enabled, you must manage both the role hierarchy and territory hierarchy” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07).

In my demo I built territories that could stand alone or be in parallel to the standard hierarchy. That word, parallel, is the whole module.

Two paths to the same account

Section titled “Two paths to the same account”

Take one account in San Diego. A rep owns it.

  • The role path. The rep owns the account, so the rep’s regional manager and the sales VP above them see it, through the role hierarchy (chapter 6, module 4).
  • The territory path. The account sits in the San Diego territory. The users in San Diego see it, and so do the users in California and West Coast above it.

Both paths work the same way upward: “Users higher in a hierarchy (role or territory) inherit the same data access as their subordinates for standard objects” (Platform Sharing Architecture). And both grant access at once. A user who’s above the owner in the role hierarchy and in a territory that holds the account gets the more generous of the two (chapter 5).

So when someone asks “why can this person see this account?”, there are now two hierarchies to read, not one.

Two hierarchies, one account Two hierarchies, one account, side by side. The role hierarchy: a sales VP, a regional manager under them, and a rep under the manager who owns an account in San Diego; the rep, the manager and the VP see it. The territory hierarchy: West Coast, California under it, and San Diego under California, which holds the same account; the users in San Diego, California and West Coast see it too. Footnote: both hierarchies grant access upward, at the same time; the user gets the more generous. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-SVA-TT-07", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "tree 0.1.0", "theme": "stevetecharc 1.4.0"} Sales VP role hierarchy sees it Regional manager sees it A rep the account is in San Diego sees it owns the account West Coast territory hierarchy sees it California sees it San Diego holds the account sees it Both hierarchies grant access upward, at the same time. The user gets the more generous. HOW TO READ IT rolls up: every role on the path sees what is below it owns the record © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

What each hierarchy should model

Section titled “What each hierarchy should model”

If you run both, give each its own job. Salesforce’s advice, when you forecast on both: “use the role hierarchy to model the HR reporting structure, then use the territory hierarchy to model the actual sales hierarchy. The territory hierarchy is best for modeling a matrix reporting structure, where someone can report to multiple managers.” If you don’t forecast on both, “it’s possible to use only the territory hierarchy as the sales hierarchy,” and then “it’s best to simplify, or flatten” the role hierarchy (Platform Sharing Architecture).

And one warning: “We don’t recommend making the role hierarchy and territory hierarchy identical because it causes unnecessary sharing activity” (same page). Two identical hierarchies give the same people the same access twice, and every change is calculated twice.

The difference that makes territories useful: a user has one role, but a territory model can put a user in many territories, and an account can be in more than one place. That’s the matrix.

Overlays

Section titled “Overlays”

Here’s where territories are most useful. An overlay is a team that works across the main structure: product specialists, key account managers, a partner team. The role hierarchy struggles with them. “Overlays are always the tricky part of the hierarchy. If they’re in their own branch, they’ll require either sharing rules, teams, or territory management to gain needed access. If they are folded into the hierarchy, there might be reporting implications” (Platform Sharing Architecture).

With territories, an overlay is just another branch. In class I build a key customers territory type, gold, silver and bronze, beside the geographic one. A key account in San Diego can sit in the San Diego territory and in the gold territory at the same time. The San Diego team sees it, and so does the key account team.

Salesforce’s own scenario: two business units, Retail Sales and Remarketing, each with its own hierarchy, both need the same account, its contacts and its activities. Their answer is territory management: “having two branches of a hierarchy that may be structured differently” (same page).

And if territories can do it, prefer them to teams: “if you can satisfy your access requirements within the territory hierarchy (like overlays), it’s better to do it there than to use teams. You’re already maintaining multiple hierarchies” (same page).

Role hierarchy or territory hierarchy Role hierarchy or territory hierarchy. Role hierarchy: models the HR reporting structure; one role per user; managers see what their subordinates own; overlays need their own branch, sharing rules or teams. Territory hierarchy: models the sales structure, including a matrix where someone reports to several managers; a user can be in many territories and an account in several; overlays are another branch, like key customers beside geography; needs its own administration. Footnote: give each hierarchy its own job; don't make them identical. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-SVA-TT-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Role hierarchy the reporting structure One role per user Managers see what their subordinates own Overlays need their own branch, rules or teams Territory hierarchy the sales structure A matrix: someone can report to several managers A user in many territories, an account in several Overlays are another branch, like key customers Needs its own administrators Give each hierarchy its own job. Don't make them identical. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Who runs the territories

Section titled “Who runs the territories”

A second hierarchy needs its own administrators, and their permissions are sharing decisions too (How Do Permissions for Territories Affect Feature and Data Access? (opens in a new tab), Salesforce Help, checked 2026-11-07):

  • Manage Territories lets someone “Create territory models and all related records,” and “Activate, archive, delete, or clone territory models.”
  • Creating account assignment rules needs “View All Records on Accounts AND Manage Territories.” Read that twice: whoever writes the rules can see every account. Give it to the few who must.
  • Administer Territory Operations lets someone “Administer specific territories and their descendants,” so a regional operations lead can run their own branch without the whole model.
  • Field-level security still applies. “The fields available for account assignment rules depend on account field-level security settings.”

And Manage Territories doesn’t open the accounts in models that aren’t active: it “Doesn’t provide access to the accounts and leads assigned to territories in planning and archived state. Only the name and ID fields appear in the list” (Territory Model State (opens in a new tab), Salesforce Help, checked 2026-11-07).

What an architect decides here

Section titled “What an architect decides here”
  • Whether the org needs a second hierarchy at all, or whether roles, rules and teams cover the access.
  • What each hierarchy models: roles for the reporting structure, territories for the sales structure, and how far the role hierarchy can be flattened.
  • That the two hierarchies aren’t identical.
  • Where overlays live: a territory branch, a team or a sharing rule, preferring territories when the model already has them.
  • Who holds Manage Territories, Administer Territory Operations, and the View All Records on Accounts that rule writers need.
  • How people answer “why can this person see this account?” across both hierarchies.

Beyond the exam: what AI changes. An agent asked “who covers this account?” has two honest answers: the owner and their managers, and everyone in the territories that hold it. If your agents explain coverage or route work, make sure they read both hierarchies, and that the people who own territory administration know their changes now move what agents can see and say.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.