The following are some rules of thumb when designing sales territory structure in Dynamics CRM:
- You don’t have to use the “Territory” entity. There is nothing magical about the standard territory entity. It may fit your structure, and it may not. Replacing it with a custom territory entity in many situations can give you a better result.
- Use security for legitimate security restrictions. It can be tempting to totally lock everybody down to only see what is in their territory. While this can be a good idea, frequently it leads to problems and is not conducive to collaboration and cross-selling. Remember the “R” in CRM stands for “relationship.” If there are legitimate reasons to restrict visibility of records, this is possible; however, if the filtering of records is for convenience purposes, there are other lightweight methods that can be used.
- Automate it. If your territory assignment follows a set of rules, these can be automated so that when a new account is added, it is assigned to the correct territory automatically, without an administrator having to do anything. This can be driven by several methods, including workflows, plugins, and batch integration jobs.
- Make it easy to administer. Over-engineered or overly complicated territory logic can sometimes break down over time. The leading reason for this is processes that are difficult to administer. If your CRM partner goes away or your CRM administrator gets hit by a bus, the territory logic should be easy to administer so that it is maintained over time.
- Make it easy to update. I have seen many territory designs that are very cumbersome to change when a territory assignment changes. For example, if your territory is driven by postal code, instead of putting the territory on the account, create a table of zip code records, and associate the territory with the zip code. With this approach, changing the territory of accounts in a certain zip code only requires update of one record, rather than updating hundreds of account records.
To your point automate it: Using Field Service and Postal Codes assigned to Territories, there’s an automation delivered within Field Service
A couple of thoughts for reasons to use the OOB Territory entity or a custom one:
There are various OOB charts, reports etc that use the existing relationships, so you will want to hide / delete these and build your own if you choose a custom entity (you might be redesigning all of this anyway so it might not be a big deal).
Bear in mind that you cannot customise the OOB relationships with Territory, so for example, the relationship from Account to Territory will be searchable even if you decide not to use the OOB entity and roll your own. I would suggest any custom entity should have a different name such as Sales Area or Region to avoid user confusion when building queries (ie Advanced Find). Otherwise users might not know whether they should use Account: Territory or Account: Sales Territory in their query.
One reason for needing some customisation to model things is when you have one manager responsible for more than one territory (temporarily or otherwise). To be the manager of a Territory you must be in it as well (the systems adds the manager automatically as a member). And you can only be in one Territory, therefore you can only manage one Territory. Options include a custom lookup to system user to replace the OOB Manager field, or a completely custom entity.