Enterprise Territory Management Record Access

Why Enterprise Territory Management Record Access Matters

In the Advanced Administrator exam, the Advanced Security and Access domain tests whether you truly understand every layer of the Salesforce sharing model. Enterprise Territory Management (ETM) is one of the most misunderstood of those layers because it sits alongside, rather than inside, the familiar stack of Organization-Wide Defaults (OWD), role hierarchy, sharing rules, and manual sharing. Sales organizations that sell by geography, industry, named accounts, or product line often cannot express their access needs through a single role hierarchy. ETM solves this by letting an account live in multiple territories at once, letting a user belong to multiple territories at once, and granting record access through those assignments without changing who owns the record.

From an exam perspective, ETM questions are scenario heavy. You will be asked to diagnose why a rep can or cannot see an account, opportunity, contact, or case, or to recommend the least-intrusive way to open access for a team organized by region. If you understand the mechanics below, these questions become predictable.

What Enterprise Territory Management Is

Enterprise Territory Management is the current generation of Salesforce territory functionality (the original Territory Management product was retired). It is enabled from Setup under Territory Settings and is built from these components:

- Territory Model: A complete territory hierarchy for the org. You can build several models for comparison, but only one model can be Active at a time. Models move through three states: Planning, Active, and Archived.
- Territory Type: A label and priority used to categorize territories (for example, Geographic, Named Account, Industry). Territory types do not appear in the hierarchy; they help organize and prioritize.
- Territory: A node in the model, such as North America, EMEA, or Enterprise Healthcare. Territories can be nested into a hierarchy.
- Territory Assignment Rules: Criteria-based rules that automatically assign accounts to territories. Rules can be inherited by child territories.
- Manual Assignment: Accounts can be added directly to territories from the territory record or from the account's Assigned Territories related list.
- User Assignment: Users are assigned to territories, optionally with a role in the territory. A user can be in many territories.
- Opportunity Territory Assignment: Opportunities carry a Territory field that can be set manually or by an Apex filter class (the default class is OppTerrAssignDefaultLogicFilter) so that opportunity access can be territory driven.

The critical idea: territory assignment is a record access mechanism, not an ownership mechanism. Assigning an account to a territory never changes the Account Owner. It simply creates additional sharing entries so that users in that territory (and above it in the territory hierarchy) can see or edit the record.

How Record Access Works

1. OWD still comes first
Territory access only matters when the OWD is restrictive. If Account OWD is Private or Public Read Only, territory settings can expand access. If the OWD is already Public Read/Write, territory membership does not add visibility (it may still add Transfer and Delete capability on accounts if that level is selected). Territories can only open access; they can never restrict it below the OWD.

2. The model must be Active
Record access is granted only by the Active territory model. A model in Planning state lets you build the hierarchy, assign users, and even run assignment rules to preview results, but users receive no access from it. When a model is archived or deleted, all access it granted is removed. Activating a different model replaces the access of the previously active model.

3. Default access levels are set in Territory Settings
Under Territory Settings, the administrator defines org-wide default territory access for four objects:
- Default Account Access: View Only; View and Edit; or View, Edit, Transfer, and Delete.
- Default Contact Access: View Only, or View and Edit, for contacts related to accounts in the territory. If Contact OWD is Controlled by Parent, contact access simply follows account access and this setting is not available.
- Default Opportunity Access: View Only, or View and Edit, for opportunities assigned to the territory (via the Opportunity's Territory field) that the user does not own.
- Default Case Access: View Only, or View and Edit, for cases on accounts in the territory.
These defaults apply to every territory in the model unless overridden.

4. Individual territories can override the defaults upward
On each territory record you can choose to use the org defaults or specify custom access levels for accounts, contacts, opportunities, and cases. A territory-level setting can be more permissive than the default but not less permissive. This lets you give the Strategic Accounts territory View, Edit, Transfer, and Delete while most territories stay at View and Edit.

5. Users receive access through territory membership
When a user is assigned to a territory in the active model, the user gains the configured access to every account assigned to that territory, plus related contacts, cases, and territory-assigned opportunities according to the access settings. The access appears on the record's Sharing button with a territory-related reason (such as Territory Assignment Rule or Territory Manual), which is the fastest way to troubleshoot why someone can see a record.

6. The territory hierarchy grants access upward
Just as the role hierarchy rolls access up to managers, the territory hierarchy rolls access up to parent territories. A user assigned to the EMEA territory automatically has access to accounts in UK, France, and Germany if those are child territories of EMEA. This behavior is always on for the standard objects involved in ETM; you do not toggle it per object the way you do with Grant Access Using Hierarchies for custom objects.

7. Accounts and users can be in many territories
Unlike the role hierarchy, where a user has exactly one role, a user can belong to many territories and an account can be assigned to many territories. Access is the union of everything granted. If an account is removed from a territory, users who only had access through that territory lose it immediately, assuming no other sharing path exists.

8. Assignment rules and the Evaluate on Save option
Account assignment rules run when the administrator runs them against the model or when an account is saved with the Evaluate this account against territory rules on save checkbox selected on the account record. Rules can be created at a parent territory and marked to apply to child territories. Manually assigned accounts are not removed when rules run; only rule-based assignments are recalculated.

9. Territories as sharing targets
Territories are first-class citizens elsewhere in the sharing model. When building owner-based or criteria-based sharing rules, you can share records with a territory or with a territory and its subordinates, and you can define the source of an owner-based rule as records owned by users in a territory. Public groups can also contain territories and territories with subordinates. This lets you extend territory-driven access to custom objects that ETM does not natively cover.

10. Permissions and visibility of the territory structure
The Manage Territories permission is required to create models, territories, rules, and assignments. Users do not need any special permission to benefit from territory access. Users with View All or Modify All on an object, or View All Data, bypass territory restrictions entirely, which is a classic exam distractor.

11. Related features that interact with access
- Collaborative Forecasts can forecast by territory when a user is designated as the territory forecast manager.
- The account page shows Assigned Territories and Users in Assigned Territories related lists, both useful for troubleshooting.
- The Opportunity Territory field lets a rep select from territories in the active model; the assignment filter can be run to populate it in bulk.
- Reports such as accounts assigned to territories, users assigned to territories, and accounts not in territories help validate coverage before activation.

Worked Scenario

Account OWD is Private. Default Account Access in Territory Settings is View and Edit. Default Contact Access is View Only. The West territory has a custom override of View, Edit, Transfer, and Delete for accounts. Maria is assigned to West; Dev is assigned to the parent territory Americas. The model is Active and Acme Corp is assigned to West by rule.
- Maria can view, edit, transfer, and delete Acme Corp and can view (not edit) its contacts.
- Dev inherits access through the hierarchy, so he has the same account access level that West grants and View Only on contacts.
- If the administrator deactivates the model, both lose access and only the owner, the role hierarchy above the owner, and any sharing rules remain in play.
- If an opportunity on Acme Corp has its Territory field blank, Maria does not get opportunity access through ETM even though she can see the account; the opportunity must be assigned to West (or a child of a territory she is in).

Exam Tips: Answering Questions on Enterprise Territory Management Record Access

1. Start with the OWD. If the question says Public Read/Write, territory settings are likely a distractor. If it says Private, territory access is a legitimate solution.

2. Check the model state. Any scenario where users assigned to territories cannot see records should make you ask whether the model is Active. Planning and Archived models grant nothing.

3. Remember access is additive and can only widen. If a question asks how to restrict access using territories, the answer is that you cannot; you restrict with OWD and expand with territories.

4. Territory-level overrides must be equal to or more permissive than the org default. Answer choices that describe making one territory more restrictive than the default are wrong.

5. Ownership never changes. If an option says territory assignment transfers ownership or changes the Account Owner, eliminate it.

6. Parent territories inherit child access automatically. If a regional director needs to see all accounts in the region, assign the director to the parent territory rather than to every child.

7. Opportunities need their own territory assignment. Account access does not automatically produce opportunity access through ETM. Look for the Opportunity Territory field or the assignment filter in the correct answer.

8. Contacts follow the account when Controlled by Parent. If Contact OWD is Controlled by Parent, there is no separate Default Contact Access setting to configure.

9. Use the Sharing button to troubleshoot. When the question asks how an admin can determine why a user has access, the Sharing button on the record showing territory-related reasons is the expected answer.

10. Know the difference between role hierarchy and territory hierarchy. Role: one per user, based on ownership, used for approvals and forecasting by role. Territory: many per user, based on account assignment, matrix structures, geographic or segment based selling.

11. Territories are valid sharing rule and public group targets. If a question involves giving territory members access to a custom object, the answer is a sharing rule shared with the territory or territory and subordinates, because ETM natively covers only accounts, contacts, opportunities, and cases.

12. Watch for the bypass permissions. A user with View All Data or View All on Account sees everything regardless of territories; this explains unexpected visibility in diagnostic questions.

13. Manage Territories is the admin permission. End users need nothing extra to receive access; do not pick answers that grant end users Manage Territories just to see records.

14. Rule runs do not delete manual assignments. If a question asks why an account stayed in a territory after rules were rerun, the answer is usually that it was manually assigned.

15. Only one Active model. Any option implying two active models at once, or that activating a second model merges with the first, is incorrect.

Master these rules and most ETM record access questions reduce to a short checklist: What is the OWD, is the model Active, is the record assigned to a territory the user is in or above, what access level applies, and is there another sharing path or bypass permission involved. Answer those five questions and you will select the correct option with confidence.