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.