Managing team selling in Salesforce can be approached in quite a few creative ways depending on your business requirements. However, there are a couple of out-of-the-box options that can significantly reduce the build time. You’re most likely familiar with account and opportunity teams, which are great for simpler use cases. But if your organization has complex, rule-based, high-volume sharing and assignment needs, look no further than Sales Territories!
In this article, we’ll go through ten of the features and considerations you should be aware of before implementing Sales Territories in your Salesforce organization.
What Is Salesforce Sales Territories?
This product might actually be very familiar to you, as it has been known for a very long time as Enterprise Territory Management. With the Summer ‘24 release, ETM changed its name to Sales Territories, and all Salesforce resources have been updated accordingly to reflect the new name. All the functionality, however, remains the same, at least for the time being.
Sales Territories is classified as a sharing mechanism in Salesforce, as it controls, based on the territories, territory rules you define, and the assignees you add, who has what kind of access to accounts, opportunities, cases, and even leads.
While this may sound complicated, for an organization that has a large team and is ready for a systematic rule-based approach, this can be a great out-of-the-box functionality to explore. From the territory hierarchy to assigning multiple users on each territory, Sales Territories can easily help you overcome the limitations that the role hierarchy or account and opportunity teams present when it comes to organizing your sales organization.
You can enable Sales Territories by yourself, directly in Setup, and decide which features you’d like to use. Salesforce provides a comprehensive implementation guide that you can use to navigate through the steps and establish if this would be the right option for your company.
What Is So Special About Sales Territories?
While Sales Territories is quite different from any other Salesforce functionality, as you can imagine, there are a few things that you should know from the get-go. Let’s deep dive into ten particularities any Salesforce Administrator embarking on this journey should know.
1. Data Model
First of all, Sales Territories introduces an array of new standard objects, which will become available in your Salesforce instance as soon as the functionality is enabled. The entire architecture revolves around the Territory2 object, which ultimately represents your various teams, as well as the Territory2Model, which will be the depiction of your entire sales organization.
ObjectTerritory2Association records, on the other hand, will be created every time an account or lead is assigned to a territory, representing the association between the two, with ObjectId being a polymorphic relationship field. This object becomes extremely handy when you’re reporting assignments and when you’d like to find out how an account, for example, got assigned to a specific territory.
While there is something to say about every one of them, knowing the relationships and dependencies between these objects right from the get-go can save you plenty of time when building your hierarchy, splitting your teams based on geographical or other criteria, as well as when planning the implementation, go-live and long term maintenance.
2. Supported Objects
Sales Territories allows you to directly assign accounts and leads to one or multiple territories from your active territory model and define what kind of access the users assigned to those territories will have over them, as well as the related records such as opportunities, cases, and even contacts if their OWD is set to private.
Using Sales Territories with leads has been made generally available in Winter ‘23, and they remain optional to use if your company decides to enable the functionality.
While accounts and leads may be assigned to multiple territories, opportunities can only be assigned to one through the Territory2Id standard lookup field on the opportunity. Keep in mind that there currently isn’t a possibility to replicate the functionality on any other standard or custom objects. This is because the ObjectTerritory2Association object is not available in Object Manager, and custom lookup fields pointing to the Territory2 object are not an option. Therefore, make sure to plan accordingly.
3. Territory Model Considerations
The territory model in Sales Territories represents your entire sales organization, organized in a hierarchical manner. Each territory can have one parent, as well as multiple children in a similar fashion to the role hierarchy, but with many more options down the line. Depending on your edition, you can have a maximum of four total territory models in any of the below states:
- Planning: This is the preview state of any territory model you create, during which you can make changes without much impact and review the setup prior to deploying it.
- Active: Only one territory model can be in the active state at a time, and this is the model on which record access and any territory forecasting will be based. Changes can still be made to this model as needed, users can be re-assigned, and new territories can be created, but these will have implications, such as sharing recalculation.
- Archived: Once a territory model is no longer in use and a new one is ready to go live, it can be easily archived from Setup. You will no longer be able to make changes to this model, including adjusting any of the account assignments or reactivating it, for example. Territories from the archived model will also be removed from the opportunity Territory2Id field automatically, but as long as you don’t delete the archived model, the past assignment will be visible in the Assigned Territories related list on Accounts. Territory forecasts and forecast types will also be deleted as a result of the archival.
Following the model creation, it is all about determining and creating the territory types your organization will be using (which can be anything you’d like), as well as starting to create the territories and organizing them in the hierarchy. The sky’s the limit when it comes to ‘slicing and dicing’ the model – you may have industry-based territories, geographical ones, or any other clusters that make sense to organize your sales team by. One model can include up to 99.999 individual territories, which can be manually created or imported.
4. Assignment Rules
One advantage of Sales Territories is the ability to assign accounts in bulk, even upon creation, through the use of object territory assignment rules. When creating them, you can pick and choose any account field to be considered and set custom filter logic. Prior to defining your rules, take a look at more details about how account assignment rules work.
The rules can be run from individual accounts as long as the checkbox is enabled on the page layout, from individual territories or the Territory Hierarchy page, for all the accounts, or for a limited number of accounts that match your input criteria. Once the run is complete, you will receive a confirmation email.
Within the Territory Settings, right above the Account Territory assignment section, there are a few dedicated settings for the opportunity assignment. You can choose the access behavior when it comes to users in parent territories, but you can also enable Filter-Based Opportunity Territory Assignment. This refers to the Territory2Id field on the opportunity being automatically updated with the use of an Apex class, which you can choose to run every time an opportunity is created.
You can create and customize your Apex class to account for any criteria you need to evaluate on opportunities in order to determine the correct Territory2Id, for example, in the event of an opportunity belonging to an account that has multiple territories or if the opportunity is marked as excluded from filter-based assignment or not.
And finally, for leads, the territory assignment in the UI is fully manual. Alternatively, it can be done through data imports, as needed, or if you have set criteria through automation upon leads being created or edited; however, the AssociationClause on the ObjectTerritory2Association record will have to be set to Territory2Manual.
5. Permissions
Companies can choose different ways to manage territory creation, deletion, and user assignment once Sales Territories are implemented. Whichever team members will conduct these operations, though, need to have the Manage Territories permission assigned. When editing a permission set, this can be found in the App Permissions category, as seen below.
This is an ‘all-or-nothing’ type of permission, and if you explore the Object Manager section, the Territory2, UserTerritory2Association, or ObjectTerritory2Association, for example, are nowhere to be found for you to control the CRUD options or field access. As a result, if you wouldn’t like territories to be deleted in the production environment, for example, a validation will have to be created to prevent user errors.
6. User Assignment
Following the territory creation, multiple users can be assigned to one territory, thus making cross-team collaboration a breeze! On the UserTerritory2Association object, you can define the different roles users can have across Territories by adding values to the RoleInTerritory2 picklist field. You can assign Users without a role, too, but this may cause confusion down the line, especially when it comes to reporting.
One thing to note here is that if users are manually assigned to territories from the Assigned Users section, the role cannot be chosen upon creation, and the record will have to be edited again for a role to be added. If you’re leveraging data imports, on the other hand, the process can be much quicker.
As you would expect, once a user assigned to territories is deactivated, the associations will be removed automatically.
Another very useful feature of Sales Territories, which you can choose to enable on the Territory Settings page, is the ability to record the user assignment activity. When turned on, this option surfaced the User Territory Association Log standard object, and a record gets created every time a user is added to the territory or has a role change. An improvement made in Summer ‘24 is that you can more granularly manage these logs with custom fields or triggers, if needed, to ensure fair and transparent compensation based on exact dates.
7. Sales Territories and Automation
While planning for the Sales Territories implementation, you might consider triggering subsequent automations based on when accounts, let’s say, are assigned to territories. A simple use case might be sending a custom notification to the Sales Manager when an account is assigned to their territory, or maybe you would also like to update existing opportunities when a new territory is assigned to the account, and so on.
At this time, the ObjectTerritory2Association object does not support triggers, meaning that such actions are not rapidly possible. One option you could explore is Batch Apex; however, the actions will not happen in real time and might consume significant resources depending on volume. Territory2, on the other hand, does have trigger support (you can find an example here), meaning that you can work with a developer for additional automation using Apex. It does not support DML operations, however, alongside another couple of Sales Territories objects, so keep this in mind while designing any solution.
You can, however, get creative with custom automations involving other objects and records. If you’re a Salesforce professional using Salesforce Flow, note that most used in Sales Territories are not available as triggering records, but you can still build complex automations that imply querying or creating them.
For example, if you have clear criteria to correctly identify both users and the correct territory from the active territory model, you could automate the UserTerritory2Association creation when a user is created or updated. Keep in mind, however, to account for all possible scenarios.
8. Reports and Queries on Sales Territories Data
Perhaps the most challenging part of reporting when Sales Territories is in use is the enablement aspect, as teams who were using account and opportunity owner-based reports in the past will have to switch to using report types based on the newly available objects.
Considering the level of detail and insights these will provide, adoption shouldn’t be a problem. Since custom report types will be needed (as no out-of-the-box ones are provided), make sure to create them accordingly and add all fields that may be leveraged by the end users.
Note that some fields will automatically surface in the standard report types using supported objects, such as the Territory Label and Description in the Accounts and Opportunity Reports.
While reports and dashboards will be great for end users and sales leadership, as a Salesforce Admin, you will most likely use queries as not only are they faster, but also allow for easier navigation to the territory records if you need to open them in the UI.
Once again, knowing how the Sales Territories objects relate with one another will come in handy as you can access any level of detail you need, from Territory2 information to user association and afferent association logs when enabled, as well as territory assignment rules, for example.
9. Field History Tracking
You are surely aware that most Salesforce objects allow admins to decide on 20 fields to enable Field History Tracking, knowing when the field was changed, who changed it, and in most cases, what the previous value was, as well as the new one. However, while you can create custom fields on the Territory2 object, the Set History Tracking button in Fields and Relationships is nowhere to be seen. Therefore, it is essential to have guidelines in place when it comes to changing territory record attributes.
Additionally, the Territory2Id standard field on the opportunity is in the same situation, even though Field History Tracking is actually available on the opportunity object. Considering the impact this field may have on your reporting, forecasting and automations, you should have a plan on how changes will be conducted in this field from the very beginning.
10. Territory Planning
Whether you’re just starting your Sales Territories implementation or you have already been using territories for a while, consider taking a look at territory planning. The reality is that territory assignment and coverage will generally be established well before reaching Sales Territories, which implies collaboration, multiple changes, as well as back-and-forth discussions between the revenue ops and sales leadership.
Salesforce Maps Territory Planning allows decision-makers to combine data from multiple sources, create various data-driven what-if scenarios, and seamlessly collaborate with multiple team members in a user-friendly, map-like interface. Once they’re happy with the end result, the desired alignment can be rapidly published to Sales Territories, removing the need to manually create territories, rules, and assign users.
Final Thoughts
All in all, Sales Territories enables your team to better manage your company’s sales organization with plenty of out-of-the-box functionality you can set up once you become familiar with the architecture and considerations.
Whether it is record access, territory coverage, or granular reporting and forecasting, this feature of Sales Cloud is one of a kind and is sure to significantly improve key processes as long as your teams and rules are clearly defined.
