Models, Types and Assignment Rules
Module 3 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 accounts need to reach people by region, segment or customer size, far past what sharing rules can hold, how do territories put accounts and users into the same buckets?
Here’s a question I ask in class. Owner-based sharing rules give you 300 buckets per object (chapter 8). How many territories can you have in Salesforce?
Somebody’s always googling. “Allocations for each territory model include up to 1,000 territories. But if you require more, Salesforce Customer Support can increase your allocations depending on your Salesforce edition,” up to 99,999 per model on some editions, with “Requests for more than 20,000 territories per model” subject to approval (Allocations and Considerations for Territories (opens in a new tab), Salesforce Help, checked 2026-11-07). So the numbers get very large. You can have a lot of buckets. But they work on accounts.
Chapter 5, module 4 put territories on the map as way 10. This module builds one.
The pieces
Section titled “The pieces”Salesforce calls the feature Sales Territories. You’ll also see its older name, Enterprise Territory Management. Here are its pieces, in the order you build them (Sales Territories Concepts (opens in a new tab), Salesforce Help, checked 2026-11-07):
- Territory types. “Territory types help you organize your territories by key characteristics important to your company.” Every territory has one. They’re for organizing only: “They don’t appear on territory model hierarchies.” Each type has a priority in a scheme you invent, so pick one that “can scale as you add more territory types.”
- Territories. “Territories organize groups of accounts, leads, and the Salesforce users who work with them.”
- The territory model. “A territory model represents a complete territory management system for your company.”
- The territory hierarchy. It “shows a model’s territory structure and serves as its main interaction point”: you create territories, run assignment rules and activate the model from there.
Territories can be geographic, like Arizona and California under a West Coast, or not geographic at all. In class I build key customers: gold, silver and bronze. Those are buckets too.
One active model at a time
Section titled “One active model at a time”You can have multiple territory models, but only one can be active at a time. Salesforce calls it the model’s state (Territory Model State (opens in a new tab), Salesforce Help, checked 2026-11-07):
- Planning. “The default state for every new territory model you create. The Planning state lets you preview a model’s territory hierarchy before deploying it.”
- Active. “Only one model in your Salesforce organization can be active at a time.” Users assigned to its territories “can access and modify accounts and leads that they’re assigned to within that model.”
- Archived. “Only the active model can be archived, and archived models can’t be reactivated.”
So you can be building a new territory model and validating it while the old one runs the business. That’s how a reorganization should work.
Read the archive line twice, though. When you archive a model, “the Territory field is reset to a blank value on opportunity records with those territories assigned,” and “Salesforce deletes your territory forecasts, forecast types, quotas, and adjustments” (same page). Archiving is one way. Plan it like a data change, not a click.
Which territory gets the account
Section titled “Which territory gets the account”Assignment rules drop accounts into territories. If the billing state equals AZ, put it in Arizona. And because you can have a thousand territories, you can have the equivalent of a thousand criteria rules dropping accounts into them.
The rules have their own logic, and it’s not quite what people expect (How Account Assignment Rules Work (opens in a new tab), Salesforce Help, checked 2026-11-07):
- All of them, not any of them. “If a territory has multiple locally defined account assignment rules, an account is assigned to the territory only if it matches all locally defined account assignment rules on the territory.”
- Rules can flow down. A rule marked “Apply to child territories” is inherited: “the rules were created somewhere higher in the territory hierarchy and also impact the given territory.”
- The lowest match wins. “If an account matches all inherited and locally defined account assignment rules for multiple territories on the same branch of the hierarchy, the account is assigned to the lowest matching territory.”
- No rules, no automatic accounts. A territory without rules “only contains accounts that were associated manually.”
- Picklists by API name. Refer to the picklist value’s API name, so a relabelled value doesn’t break the rule.
- Fifteen per territory. Each territory can have up to 15 assignment rules and 1,950 assigned users (Allocations and Considerations for Territories).
So an account in San Diego that matches the San Diego rules lands in San Diego, not also in California. If you need it formally in both, the parent needs its own rule. And an account can sit in more than one branch: a geographic territory and a key customer territory at the same time.
When the rules run
Section titled “When the rules run”This is the part people miss. In my demo in 2023, the rules fired when the account was created. I changed my custom territory field on an existing account, and nothing happened until I ran the rules again.
Today, for an edit on the screen, a Salesforce knowledge article says it depends on a checkbox you add to the account page layout: Evaluate this account against territory rules on save. “The user can uncheck the ‘Evaluate this account against territory rules on save’ checkbox on the edit page, and territory assignment rules will not be run” (Run territory assignment rules when you edit an Account (opens in a new tab), Salesforce knowledge article 000385116, checked 2026-11-07).
In Lightning Experience there’s more to it, and Salesforce says so in a known issue. “Inline edit in Lightning does not run the rules. Users need to click on Edit button.” And after a second review: “regardless of having the field on the layout that territory assignment rules are not expected to run unless using the edit button on the account record” (Territory Assignment Rules in lightning do not run when the “Evaluate this account against territory rules on save” field is not on the layout (opens in a new tab), Salesforce Known Issue, last updated 2024-02-09, checked 2026-11-07). So a user who changes the field in place, with the pencil, doesn’t move the account.
And you can always run them yourself. “When you run rules from Setup, accounts are assigned to territories according to your rules if your territory model is in Active or Planning state,” for all accounts or a filtered subset, and “Running rules can take a long time” (Run Assignment Rules for a Territory (opens in a new tab), Salesforce Help, checked 2026-11-07).
So test it in your org: change the field a rule reads, on the screen and through your integrations, and see whether the account moves. If it doesn’t, you might need a flow or a scheduled job to trigger the recalculation. There may be a delay when that field changes, and the access is wrong until it runs.
Users in territories, and what they get
Section titled “Users in territories, and what they get”Then you put users in the territories. That grants them access above and beyond the normal sharing rules. In my demo, each territory also sets how much its users get: view or edit, on the account, its opportunities and its cases. Today each territory has four of these settings, one each for accounts, opportunities, cases and contacts. Account access can be Read Only, Read/Write or Owner; opportunity, case and contact access can be Private, Read Only or Read/Write (Territory2 (opens in a new tab), Object Reference for the Salesforce Platform, fields AccountAccessLevel, OpportunityAccessLevel, CaseAccessLevel and ContactAccessLevel, checked 2026-11-07). So you could have one set of settings at the state level and different ones at the city or sub-region level.
Chapter 7, module 1 showed that territories can also be members of public groups and targets of sharing rules. Module 4 puts territories beside the role hierarchy: two hierarchies on one account.
Your own buckets, by automation
Section titled “Your own buckets, by automation”Here’s the trick I like. You can build your own model structure: add a custom field on the account, say a special territory code, and an assignment rule that drops matching accounts into a special territory. It can stand alone or run in parallel to your standard geographic hierarchy.
And remember the teams trick from module 2. An automation can drop someone into a team. An automation can also drop an account into a territory, and put a user in a territory. So you could have a thousand territories with your automations putting people and accounts in them. Instead of programmatic sharing (chapter 11), you can have programmatic territory assignment, on Salesforce’s own screens, where admins can see it.
One limit: territories are about accounts, their opportunities and cases, and leads. If you’re talking about a custom object, territories don’t apply.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of a territory model: a state rule, a city under it, and a special territory driven by a field of its own. The note under the video says what’s still right and what’s changed since.
What an architect decides here
Section titled “What an architect decides here”- Whether accounts need territories at all: how many buckets (the number of zeros, chapter 7 module 4), and whether owners or criteria could do it instead.
- The territory types and their priority scheme, chosen to grow.
- The model lifecycle: who builds the next model in Planning, how it’s tested, and when the active model is archived, knowing that forecasts, quotas and opportunity territories go with it.
- The assignment rules: all-must-match on each territory, which rules apply to child territories, and picklists by API name.
- When rules run in your org, on the screen and through integrations, and what automation reruns them.
- Who’s in each territory, and how much each territory gives on accounts, opportunities and cases.
- Where automation assigns accounts and users to territories, and who it runs as.
Beyond the exam: what AI changes. Territories are a structure an agent can read and explain: “which territory is this account in, and who covers it?” That’s useful. But an agent that changes an account’s address, segment or size may move it into a different territory, or, if the rules don’t run on that update, leave it in the wrong one. List the fields your assignment rules read, check which agents can write to them, and test whether a change made by an agent reruns the rules.
Explore
Section titled “Explore”- Sales Territories Concepts (opens in a new tab), Salesforce Help (checked 2026-11-07)
- Territory Model State (opens in a new tab), Salesforce Help (checked 2026-11-07)
- How Account Assignment Rules Work (opens in a new tab), Salesforce Help (checked 2026-11-07)
- Run Assignment Rules for a Territory (opens in a new tab), Salesforce Help (checked 2026-11-07)
- Run territory assignment rules when you edit an Account (opens in a new tab), Salesforce knowledge article 000385116 (checked 2026-11-07)
- Territory Assignment Rules in lightning do not run when the “Evaluate this account against territory rules on save” field is not on the layout (opens in a new tab), Salesforce Known Issue (checked 2026-11-07)
- Territory2 (opens in a new tab), Object Reference for the Salesforce Platform (checked 2026-11-07)
- Allocations and Considerations for Territories (opens in a new tab), Salesforce Help (checked 2026-11-07)