This post is the continuation of my study notes for  Sharing and Visibility Designer Architect Certification. Previous post was regarding Salesforce Sharing and Security Cheat Sheet. Enterprise Territory Management is a very important topic and having a clear understanding will definitely going to help in passing the certification as well as implementing it for your own project.

Nice to check out: 

Important Note:

  • Original Territory Management is only available with Customizable Forecast.
  • Enterprise Territory Management works with Collaborative Forecast. It will not work with Customizable Forecast.

Territory:

Group of Accounts and Sales reps who work for those accounts.

Territory Type:

This is the criteria to group territories. Every territory must have one Territory Type, but it will never appear in the Territory Hierarchy

Territory Type Priority:

Helps you to create priorities for your territory type.

Territory Model:

  • Creates the entire Territory Hierarchy.
  • It allows to create multiple territory hierarchy and test that before activating.
  • Number of territory models depends on the Salesforce edition.

Territory Hierarchy:

  • Shows the model’s territory structure.
  • You can run assignment rules at the model level or individual territory levels.
  • Your territory hierarchy in active territory model also determines the forecast hierarchy for territory forecast.

Territory Model State:

  • Three states – Planning, Active or Archive.
  • Only one territory can be in Active state.
  • Multiple territories can be in either Planning or Active state.

User Access for Territory Records:

  • Define Account access in Territory Settings when enabling the Enterprise Territory. You can change it later as well.
  • Account Access is:
    • Users in the territory can view and edit the Accounts in the same territory or
    • Users in the territory can view, edit, transfer and delete the Accounts in the same territory.
  • Contacts, Opportunity and Cases will have the default access defined in Internal Access settings if the access level is either Controller by Parent or Public Read/Write/Transfer.
  • If the Internal Access for Contacts, Opportunities and Cases are configured anything apart from Controller by Parent or Public Read/Write/Transfer, then you can set the access as –
    • View all contacts/cases/opportunities associated with Accounts in the same Territory irrespective of who owns the contact/case/opportunity.
    • View and Edit all contacts/cases/opportunities associated with Accounts in the same Territory irrespective of who owns the contact/case/opportunity.
  • This settings can be changed when creating Territories. You can change it to make it more restrictive (Territory Settings : View and Edit, whereas Territory Hierarchy Settings: View, Edit, Transfer and Delete) as well.
  • Territories access level is inherited by the parent territories above it in the territory hierarchy. Example: India (View and Edit) is the parent of Kolkata (View). Users assigned to India territory will have View access to Accounts assigned in Kolkata territory.

Assigning Territories to Accounts:

  • “Manage Territories” permission is required to assign accounts to territories.
  • Either manually assign accounts or write assignment rules.
  • Assignment rules can be inherited to child territories by selecting the option while creating the assignment rule. If selected, the criteria from the parent territories is not required to be mentioned in the child territories assignment rules.
  • Accounts can be associated with multiple territories.
  • Manually added Accounts will remain in the Territories until and unless it is removed manually.

Assigning Territories to Users:

  • When users moved to a new Territory. they have the option to take their existing Accounts and Opportunities with them,

Assigning a Territory to an Opportunity:

  • From the opportunity detail page, select the territory.
  • You will only get those territories where –
    • Both the opportunity owner and opportunity’s account owner are present,
    • you have administrative access and also associated with opportunity’s account.
    • you have administrative access that are above the opportunity’s account in the territory hierarchy.

Filter based Opportunity Territory assignment:

Assigning Territory Roles to Territory Users:

  • You can define custom roles under User Territory Assignment -> Role in Territory.

Optimize Performance:

  • Always select inherited rules to child territories which will prevent rule engine to evaluate more territories and thus improving performance.
  • Always start with the lowest level of territory hierarchy and then move upwards. With this approach, it will not recalculate Account, Contact, Opportunity, Case access for the same territories.
  • Always define criteria on Numeric fields, rather than String field while creating assignment rules.
  • Keep the assignment rule restrictive by avoiding lots of OR condition.
  • More than 10,000 records associated with single territory will always create performance issues.
  • For best performance, single user should not be liked with more than 3 territories.
  • If needed more users (more than 1,500 users) in a single territory, better to use user-to-territory assignment through API.
  • You should not run assignment rule for each Account update. You can eliminate that by not selecting the option evaluate this account against territory rules on save. The reason is even though you are editing single account, but the assignment rule will run for all the accounts, which can cause performance issues.

Difference between Role Hierarchy and Territory Hierarchy:

  • Role Hierarchy is perfect for managing organization structure where one person reports to only one person.
  • Territory Hierarchy is perfect for managing matrix reporting structure where one person reports to multiple person.

When to use what? Role Hierarchy or Territory Hierarchy:

  • You should use Role hierarchy to use implement your organization hierarchy, reporting rollups, approvals.
  • Then use Territory hierarchy to extend access to records based on user’s territory assignment.

Forecast Manager:

  • To see the rolled-up forecast, assign Forecast manager to parent territory.
  • Forecast manager can view and adjust forecasts.
  • Without Forecast manager,  users can view and adjust only their own forecasts, but can’t adjust other’s forecast.

Please let me know if you think I should add something here in the comment section.