A rep complains forecasts don’t match what they see in Pipeline View. You dig in. Half the deals are owned by someone who left in Q3. The new rep sees them — but they don’t roll up to her forecast. Someone “fixed” it by adding her to a group. The group shares records. It doesn’t reassign forecast credit.
This is the territories vs groups trap. Six hours a quarter, every quarter, until you decide.
What each one actually does
Territories restructure ownership and forecast hierarchy. Groups share visibility on records already owned by someone else. They look similar in the UI. They’re not the same primitive.
- Territory: a unit in a parallel hierarchy. Has its own manager, its own forecast rollup, its own assignment rules. A record can belong to multiple territories.
- Group: a flat bag of users (or roles, or sub-groups) used for sharing rules, approval routing, and “assign to group” round-robin.
Forecasting only follows territory hierarchy when Territory Management is enabled. Otherwise it follows role hierarchy. Groups never touch forecasting.
The decision tree
Three questions. Answer in order. Stop at the first yes.
- Do reps own different geographies, products, or account tiers that need separate forecast rollups? Territories.
- Do you need a non-owner to see, edit, or be reminded about a record without changing the rollup? Groups via sharing rules.
- Is it just “I want round-robin assignment to a pool”? Group + assignment rule. Don’t enable territories.
Most teams below 30 reps don’t need territories. They need clean roles, two or three groups, and a decent assignment rule.
When territories actually pay off
You have AE pods by industry and AMs by region. Same accounts, different rollups. A West-region AM forecasts renewals; a vertical AE forecasts expansion. Without territories you’ll fake it with custom fields, lookup chains, and reports that quietly stop matching reality.
Turn it on when at least three of these are true:
- More than one rep can legitimately work the same account
- Forecasts must split by dimensions other than role
- Assignment is rule-driven (geo, industry, revenue band) not manual
- You’ll commit to maintaining the hierarchy quarterly
Turn it off if you’re just trying to share records. Use groups.
When groups are enough
Groups carry the load for 80% of mid-market orgs. They’re cheap. They’re reversible. They don’t break your reports if you delete one.
- SDR pool feeding AEs → group + round-robin
- CS team co-watching at-risk accounts → group via sharing rule
- Deal desk reviewing >$50k opps → group as approval recipient
- After-hours support catch-all → group + escalation rule
The mistake is layering territories on top later “for forecasting” without resetting ownership. Now both run. Now nothing reconciles.
The orphan-record problem
A rep leaves. Their deals are reassigned to their manager. If you have territories, you also need to confirm the territory assignment moved. If you don’t, the deal stays in the old territory, the old territory has no manager, and forecast rollup is silently zero for that bucket.
Run this monthly. It catches orphans before forecast lock.
// Deluge: find deals owned by inactive users or in empty territories
inactive_owners = zoho.crm.searchRecords("Users", "(status:equals:inactive)");
orphan_deals = List();
for each user in inactive_owners
{
user_id = user.get("id");
deals = zoho.crm.searchRecords("Deals", "(Owner:equals:" + user_id + ")");
for each deal in deals
{
orphan_deals.add({
"id": deal.get("id"),
"name": deal.get("Deal_Name"),
"amount": deal.get("Amount"),
"stage": deal.get("Stage"),
"owner": user.get("full_name")
});
}
}
if(orphan_deals.size() > 0)
{
zoho.cliq.postToChannel("revops-alerts", {
"text": "Orphan deals detected: " + orphan_deals.size().toString(),
"attachments": orphan_deals
});
}Run it on first of month, 6 AM. Don’t wait for the quarter-end fire drill.
Migration: groups to territories without breaking forecast
You started with groups. You’ve outgrown them. Don’t flip the switch on a Tuesday.
- Freeze new deal creation for 2 hours in a sandbox copy. Map every active group to a territory or a sharing rule. Some groups become territories. Some don’t.
- Build the territory hierarchy mirroring how you actually want forecasts to roll. Not your org chart. Your forecast chart.
- Write assignment rules that match the territory. Test with 10 sample deals. Verify rollup in Forecasts module.
- Communicate the cutover. Reps will see their pipeline change shape. If they don’t know why, they’ll file tickets.
- Cut over end of month, after forecast lock. Never mid-quarter.
The pattern: territories define rollup, groups define collaboration. Don’t make groups carry forecast logic. Don’t make territories carry collaboration.
Reporting gotchas after you switch
Once territories are on, two report fields exist: Owner and Territory. Reports filtered only on Owner will miss records visible to a user via territory but owned by someone else. Reports filtered only on Territory will miss records owned by users not assigned to a territory.
Build a base report that uses “My Territories’ Records” as the criterion. Save it. Clone for variants. Don’t let people build new pipeline reports from scratch — they’ll pick Owner and lose half the deals.
The cost nobody talks about
Territory Management is in Enterprise and above. Once enabled, you can’t cleanly disable it. The data model changes. Existing reports get rewritten. Sharing rules behave differently. Plan a one-way door.
Groups are free. Reversible. Boring. That’s a feature.
For the broader automation landscape that interacts with both, see the Zoho CRM automation deep dive. For when blueprint stages overlap with territory transitions, see the blueprint vs workflow decision.
Bottom line
Territories restructure ownership and forecast. Groups share access. If you can’t draw your forecast on a napkin in 30 seconds, don’t turn on territories. If you can, and the napkin has more than one axis, you probably need them. Audit orphans monthly. Migrate end of quarter. Never mid-month.
