Territory Hierarchy Best Practices
Use Territory Management to Simplify the Sales Branch of Your Role Hierarchy
When modeling your territory hierarchy, remember that access provided by territory management automatically rolls up to your role hierarchy. Trying to duplicate your territory structure in the sales branch of your role hierarchy is unnecessary and redundant.
Instead, use your role hierarchy to configure management relationships, reporting rollups, approvals and other hierarchically structured workflows. Simplify the Sales branch of your role hierarchy to only contain roles for these purposes. Then use Territory Management to extend access to Accounts and Opportunities based on the users' territory assignments.
Add Territories that have Forecast Managers
Applies to Territory Management 1.0 and customizable forecasting. This content will be updated when integration between Territory Management 2.0 and collaborative forecasting is updated.
When forecasting in Salesforce, only add territories to a territory hierarchy if they have forecast managers who have access rollup requirements. If you forecast in Salesforce for a territory that has no forecast manager, the territory and all of its subordinate territories are not included in your forecasts. If your parent nodes don’t require forecast managers, you still must add placeholder forecast managers to ensure that your forecasts roll up to their parent nodes.
Add Inherited Account Assignment Rules
When you add parent territories to the territory hierarchy, it’s also a good idea to add inherited account assignment rules to those territories. If you follow this practice, you can both prevent the rules engine from having to evaluate entire branches of your territory hierarchy and improve your overall sharing performance. See “Managing Account Assignment Rules” in the Salesforce Help.
Re-parent from the Bottom Up
When modifying your territory hierarchy, re-parent each node of the territory from the bottom up to avoid having to recalculate access for the same territories.
Consider Enabling Granular Locking
Certain territory hierarchy-related operations require exclusive administration locks, which might temporarily prevent administrators within your organization from performing administrative activities or affect some end user group membership operations, such as portal user provisioning and portal account ownership changes.
In some scenarios you can improve the performance of some locking operations by enabling granular locking. Granular locking analyzes the operation and attempts to lock only the modified portions of the table, which can reduce the amount of locks affecting other users. Operations that do a full table (Group) lock and therefore might benefit from granular locking include:
- Adding, deleting, or moving a user from one territory to another
- Re-parenting a territory
- Creating or deleting a territory within the hierarchy, even if there is a user in the territory
- Adding or removing a forecast manager
Granular locking will not improve performance for the following tasks, because these tasks either already do row-level locking or don’t require a lock:
- Modifying access levels
- Making manual assignments to an account
- Adding, deleting, or updating rules
- Previewing account assignments
- Assigning an object to or removing an object from a territory
For more details on granular locking, see Designing Record-Level Access for Enterprise Scale.
Integrate with an External Single Source of Truth
You may already have an existing system for managing territories that you consider your Single Source of Truth (SSOT). Or, you might have a complex and large set of territories that might even span across multiple organizations. In these scenarios, you may want to consider integrating your external SSOT with Salesforce territory management. You can create custom fields on Territory that are External IDs into your SSOT to make this integration easier.
If you integrate your territory hierarchy with an external SSOT, you can clone your hierarchy from the SSOT and use it to help you manage your territories. This kind of customization generally has a low impact on performance, and your cloned hierarchies stay in sync with your external SSOT at all times.
Territory Assignment Best Practices
Use Numeric Fields
When defining the filter logic for your assignment rule, don’t evaluate number criteria as text criteria. If the data in a field is numeric, ensure that the field is defined as a number field; number fields defined as text fields hinder evaluation performance. See “Changing Custom Field Type” in the Salesforce Help.
Instead of defining criteria on string fields, consider defining criteria on numeric fields. Operators on string fields are case insensitive, and case insensitivity can affect performance.
Architect for Peak Performance
- Use inherited criteria wherever possible to avoid having to calculate entire branches of the territory hierarchy when you’re assigning accounts.
- If standard account assignment rules are not flexible enough to meet your sharing requirements, consider using assignment rules on formula fields.
- Make your direct and inherited rules as restrictive as possible to obtain peak performance.
Consider Alternate Approaches for Criteria Fields
- When the number of criteria entries doesn’t meet your business requirements, use formula fields to combine multiple data fields on an account. For example, if you need more fields than the 10 criteria field limits, you could combine, say, the BillingCountry and BillingState fields into a single formula field.
- When criteria are based on an account’s related records, use rollup summary fields or triggers to move data to the account object. Then use those fields to drive account assignment rule criteria.
Don’t Use Assignment Rules to Clean Data
Avoid using territory assignment rules to cleanse dirty data, especially when you’re determining which account a lead should be associated with. Perform data cleansing outside of the territory assignment engine to ensure a leaner territory rule structure.
Correctly Define Named Accounts
Most companies that manage their sales organizations by territory have named accounts, major accounts assigned to the sales representatives who can best manage them. A few of the main strategies for defining named accounts within the standard account assignment rule structure include:
Defining accounts by name in the rule criteria. Because account names can be very long, we generally recommend this strategy for smaller customers who would have few named accounts defined within a territory.
Defining criteria based on account numbers, which are more concise than account names. This strategy allows organizations to include more named accounts within a territory.
Developing a customized solution if neither of the previous solutions provide appropriate scalability
Avoid Using Rules to Assign Leads
When assigning leads, use the standard lead assignment rules or a separate custom assignment process — don’t consolidate data into a shared rule structure. If you do need to use a shared rule structure, have relatively few lead assignments, and don’t need to realign your leads, consider having your lead assignment rule use standard account assignment rules.
To obtain the assignments, write a trigger that:
- Creates a dummy account with the lead’s data
- Shares the lead to the territories assigned to the dummy account
- Rolls back the dummy account so that it doesn’t get created in the system
You can also use this architecture and standard account assignment rules to assign objects other than leads.
Use Sharing to Provide Overlay Access for Opportunities
If you need to overlay your territories on your opportunities, you could customize territory management to allow this, but this type of customization can become very complex and difficult to manage.
Instead, consider configuring profiles, sharing rules or manual shares to provide overlay access.
Use Force.com APIs to Automate Rule Maintenance
Some customers realign their territories monthly, weekly, or even daily, sending frequent updates to an extremely large rule base. In these cases, customers can benefit from automated processes that update the rule structure. The Salesforce standard rule structure is relational and provides enough flexibility for our broad customer base. Although maintaining that standard rule structure is technically feasible for our larger customers, the relational structure makes automated maintenance very complex.
Consider using the SOAP or REST API to automate the maintenance of the standard account assignment rule structure. If possible, avoid de-normalizing the standard rule structure into a custom rule structure.