12

Territory Management

As we touched upon in Chapter 2, Data Modeling and Database Design, territory management is used to facilitate the automatic sharing of account records based on rules that pertain to how those records are assigned to users based on the criteria of the record. This chapter explains territory management in more detail and how it pertains to data model design on Salesforce.

In this chapter, we’ll cover the following topics:

• Enterprise territory management overview
• Implications of territory management on data model design and sharing records

Let’s begin our explanation of territory management with an overview.

Enterprise territory management overview

Salesforce fully supports the concept of Sales Territories to assign accounts and opportunities to individuals or teams of salespeople. With these territories set up, automatic assignment of accounts and opportunities can be set up based on rules, and management reporting in the form of reports and dashboards is possible. A feature of Enterprise Territory Management is that the built territory model can be tested before it has been activated, allowing for testing before changes are rolled out to users.

Important note

Legacy Territory Management (sometimes known as the original Territory Management module) was retired in the Summer 2021 release of Salesforce, and as such is not relevant to the exam. More information about this announcement is available at https://help.salesforce.com/s/articleView?id=000318370&type=1.

Under the hood, Enterprise Territory Management is a way of sharing. By that nature, Salesforce utilizes a rules engine, as determined by how you set up Enterprise Territory Management to perform sharing and associated recalculations on the fly.

Before we get into the specifics of how Enterprise Territory Management is set up, let’s cover some terminology that is specific to Enterprise Territory Management, as follows:

• Territory
• Territory Type
• Territory Type Priority
• Territory Model
• Territory Model State
• Territory Hierarchy

We’ll cover each of these terms, beginning with the definition of a territory.

Territory

A territory can be thought of as a grouping of account records and the users in your Salesforce instance that work with those account records. Territories are created from territory types. Territories can be hierarchical. For example, it’s entirely possible to have a territory called the United States, with Northwest, Northeast, Southwest, Southeast, and Central Territories as children. Territory records contain several key pieces of information, such as the following:

• Assigned users to the territory
• Any assigned accounts
• Territory/Account Assignment Rules (the characteristics of an Account that mean that it will be assigned to this territory)

Next, let’s look at the definition of a territory type.

Territory Type

Territory Types are used to organize and create Territories based on criteria such as account size, account billing state, or named accounts. When Territories are created, they are created from a territory type. Territory Types do not appear on the territory model Hierarchies that are created as part of the Territory Management setup.

For example, a territory called UK County-Based Accounts could be created whereby territories can be created based on the UK County value in the state picklist of the Account records.

With territory type now understood, let’s turn to territory type Priority.

Territory Type Priority

Territory Type Priority is a custom scheme you define, and it is used to assist when creating territory records from the territory types you’ve defined. For example, you may have territory type Priority values of 1 through 5 to denote the priority of the territory record when it is created to align with the sales strategy of your business. This could mean that the Southwest Territory is given a priority of 1 as it is where your business expects to see the most growth this coming financial year. Essentially, Territory Type Priority is used to ensure that the right territory types are prioritized when creating new territory records.

Now that we have covered the definition of Territory Type Priority, let’s explore the territory model.

Territory Model

The territory model is the representation of a complete territory management system, as defined by you for your Salesforce instance. You can have multiple territory models, but only one can be active at any given time. Salesforce provides a nice graphical hierarchy for territory models, which assists us in visualizing how Territories are organized, including the hierarchies. territory models allow you to test how Account and User record assignments will work, and as such allow you to try seeing how implementing a certain territory model will affect things before activating it.

Important note

Salesforce Enterprise Edition only allows two territory models to exist at any one time. Performance and Unlimited editions can have four territory models. The same limits apply to Salesforce Sandbox environments that are created from a production instance utilizing one of these Salesforce editions. Remember only one territory model can be active at a time.

With territory model covered, let’s now look at the definition of a territory model state.

Territory Model State

Territory Models are assigned a state value to quickly allow the status of a given territory model. There are three values available, as follows:

• Planning: All territory models default to this value. It can be thought of as signifying the territory model is being developed/is in draft status.
• Active: The territory model is active. Remember, only one territory model can be active at any given time.
• Archived: A previously active territory model is archived as another territory model has been activated. Once a territory model has been archived, it cannot be reactivated.

Important note

When a territory model is archived (or you decide to delete a territory on an active territory model), the Territory field on Opportunity records is set to a blank value on Opportunity records that had a previously active territory assigned.

When activating or archiving a territory model, there may be errors that occur. If so, the status of the territory model will be set to either Activation Failed or Archiving Failed. Salesforce will send you an email containing details as to why the failure occurred.

Next, let’s look at the Territory Hierarchy.

Territory Hierarchy

A Territory Hierarchy shows a structured view of the territory model. The Territory Hierarchy is the main interaction point with the territory model and is the place where Territories can be created, edited, and deleted. It’s also where assignment rules can be executed, and Opportunities can be assigned to Territories.

With the Territory Hierarchy definition covered, let’s delve deeper into how Enterprise Territory Management is set up.

Implications of territory management on data model design and sharing records

Territory management essentially facilitates the automatic sharing of records based on a rule set, as defined by the territory model that has been activated in your Salesforce instance. How Organization-Wide Defaults (OWDs) are set up will have an impact on the way the territory management implementation for your organization works. This is because the sharing afforded by territory management and the assignment of Accounts and Opportunities may or may not offer any further record access in addition to the sharing already in place. In such cases where there is no difference in the sharing of records, territory management essentially becomes a tool for organizing records. Territory management report types can be utilized to provide reporting based on Accounts and Opportunities being assigned to users, as per the active territory model.

In instances where the default Account and Opportunity model is set to Private, then territory management can be used to set the access level for Account and Opportunity records that are shared with users. For example, Accounts and Opportunities may be Private as per the configured OWDs for your Salesforce instance. Territory Management can be used to configure record access to be Read or Read and Edit on Opportunity records that are shared with users.

If a territory is part of a Territory Hierarchy, then Territory records above an assigned territory in the Territory Hierarchy inherit the sharing of the assigned territory. Let’s put that as an example to explain it in more detail.

Let’s imagine that the Territory Hierarchy shown in the following diagram has been configured. Let’s assume that the OWD has been set to Private for Account and Opportunity records, and users assigned to the Territories don’t otherwise have access to the records without territory management in use. The sharing denoted in the following diagram will be the sharing as set for each territory in the Territory Hierarchy:

Figure 12.1 – An example territory model

In our example, users assigned to the East Anglia territory record will have Read access to the Essex, Suffolk, and Norfolk Territory records. Despite the access on the East Anglia Territory being R/W (Read/Write), Territory Access isn’t inherited. Therefore, the access to the child Essex/Suffolk/Norfolk records will remain as Read-Only.

Important note

Automatic territory assignment to Opportunity records requires editing a generated Apex class, which requires Apex coding skills. Apex coding is outside the scope of the exam, so it won’t be covered in this book.

Territory assignment for Account records can be configured to run automatically as part of the declarative functionality for Account Assignment rule creation from the Territory Model Hierarchy screen.

Now we understand how territory management is another layer in the Salesforce sharing model for sharing Account and Opportunity records, let’s take a moment to think about how territory management opens sharing to other child records associated with an Account or Opportunity.

For example, a custom object that has a Master/Detail lookup to an Account means that the records of that custom object that look up to an Account shared to a user through territory management will be visible by the user. This can inadvertently open record access beyond what was envisaged before territory management was implemented, and therefore consideration should be given to the territory model. Layering in criteria-based sharing rules that apply to a shared Account or Opportunity record means that other unintended side effects may occur. Therefore, testing your model is crucial for it to be successfully rolled out to an organization.

As a reminder, Master/Detail relationships mean that users inherit the access they have to the parent record when working with the child records. This can have profound implications for the design of your data model, as territory management may give unintended heightened access to other object data (such as edit access depending on the territory setup). Therefore, data model design, relationships between objects, and other factors related to the setup of the data model will be impacted by a territory management implementation.

Let’s take a quick look at an example to explain some unintended side effects of implementing territory management, meaning that a data model may have to be revised:

Figure 12.2 – Data model example

Using this data model example as our guide, we can see that a Private OWD is in play. Pay attention to the Master/Detail relationship from Account to the custom Account Plan object (denoted as AcctPlan__c).

Now, let’s imagine we’ve enabled a territory model that shares (with read and edit access) Account records to certain users. Those users now have access to the Account Plan, so much so that they can edit the Account Plan records. Let’s assume that only the Account Owner should ever be able to create or edit the Account Plans for the Account record. Therefore, it may have been wiser from the outset to have the relationship type set to a Lookup type from Account Plan to Account (as Lookups allow a specified sharing default to be set as per the OWDs). Of course, hindsight is a wonderful thing, but careful planning also pays dividends, particularly when dealing with the side effects of sharing. Salesforce provides other methods of sharing records, meaning that private, read-only access to Account Plan records would be possible with a territory.

Thinking back to the basics of OWDs and Salesforce instance setup, organizations that have an internal OWD of Public Read-Only or Public Read/Write for Account records won’t see a record visibility increase for users. Those with Public Read-Only can use territory management to give a higher level of access to certain Account records to users if a use case for sharing lends itself to territory management.

Now that we’ve covered how territory management affects sharing, and how implementing territory management may affect the design of your data model, let’s summarize what we’ve covered in this chapter.

Summary

In this chapter, we looked at Enterprise Territory Management and explored how it affects solution design and sharing on the Salesforce platform. We now understand how territory management can affect data model design and how record sharing is affected. We walked through a couple of examples to bring these points home and emphasized why it is crucial that data model design, sharing, and other factors relating to the setup of your Salesforce instance are evaluated thoroughly before implementing territory management.

With Enterprise Territory Management now under our belts, we can test our knowledge of everything we’ve covered in this book as we look to Chapter 13, Practice Exam Questions.

Practice questions

Test your knowledge of the material we covered in this chapter by attempting the following practice questions:

1. Salesforce had two types of territory management, but only one type is now supported. What is it known as?
2. What facility allows you to configure parent/child Territory associations?
3. Which feature of territory management allows for certain territory types to be prioritized when creating Territories from a territory type?
4. Let’s imagine there is an active territory model that’s granting selected users read/write access to Account records belonging to a Territory. The Account record has a Master/Detail relationship with a custom object that contains child records associated with the Account record. What access will the users have to the custom object records?
5. True or false? Territory Management Models can be tested before they are activated.
6. True or false? Out of the box, only Account records can be assigned using territory management in a declarative manner.
7. How are selected (that is, using a filter) Opportunity record assignments configured using territory management?
8. In its simplest definition, what does territory management do?
9. With territory management, if a user is assigned to Accounts belonging to a particular Territory with a Read-Only access level, what access do they have to the parent Territory?
10. What are the three territory model states?

Answers

How did you get on answering the practice questions? Check out your answers here:

1. Enterprise Territory Management.
2. The Territory Hierarchy.
3. Territory Type Priority.
4. Read/Write.
5. True.
6. True
7. They aren’t configured as such. Territory Management Opportunity Assignment works by editing an Apex class.
8. It shares Account and Opportunity records based on criteria associated with the records to select sets of users.
9. Read-Only, as territory management propagates sharing access upwards.
10. Planning, Active, and Archived.

Further reading

To learn more about territory management, check out the Territory Management Implementation Guide at https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/salesforce_implementing_territory_mgmt2_guide.pdf.