Territory Management
Administrator Guide. Territories decide which salesperson's patch a client entry belongs to, and Territory Alignment applies those rules to your client list in bulk. Because a bulk run can change thousands of records at once, nothing is written until you have seen the list of changes and approved it, and every run can be undone.
Open it from the ribbon: Setup ▸ Territory ▸ Territory Management.
The window has two tabs (Setup to define the territories and Alignment to apply them) and a Close button.
The Setup tab
| Part | What it is |
|---|---|
| The list | Every territory, in priority order: the one at the top is tested first. Two columns: Territory and Account Manager. |
| Add… | Create a territory. |
| Delete | Delete the selected territory (see Deleting a territory below). |
| Modify… | Edit the selected territory's name, account manager and rules. |
| Move Up / Move Down | Change the priority order. |
| Source CRM Catalogs… | Store the rules of older territories for the source CRM too, after a dry run (see below). |
| Description | A read-only summary of the selected territory: its account manager, whether it is active, its rules written out in plain English, and a Source CRM: line saying whether the source CRM's desktop applies the same rules. |
Delete, Modify…, Move Up and Move Down stay greyed out until you select a territory; Move Up is also off for the top row, and Move Down for the bottom one.
Adding or modifying a territory
Add… and Modify… open the same dialog.
- Territory name: required, up to 79 characters, and it must be unique.
- Active: an inactive territory keeps its definition but is skipped by Align Territories.
- Account manager: tick one or more users.
- One manager: alignment sets each matched entry's territory and its Account Manager.
- None, or more than one: alignment sets the territory only and leaves each entry's Account Manager exactly as it is. (Recording several account managers on one client entry needs rows in the record-access security table, which TechieCRM deliberately does not write.)
- Alignment rules: the conditions an entry must meet to join this territory. Use Add Rule… / Edit Rule… / Remove Rule. A rule is a field, a condition and a value:
| Fields | Conditions |
|---|---|
| Country · State / Province · City · Zip / Postal Code · Name · Company (Firm) · Address line 1 · Department · Division · Owner · Account Manager | is · is not · begins with · contains · is one of · is empty · is not empty |
For is one of, separate the values with commas: BC, AB, SK. Comparisons ignore case and
surrounding spaces.
All the rules must be true for an entry to join the territory.
- Under the rules, a line tells you, as you edit, whether the source CRM's own desktop will apply the same rules (see Rules that also work in the source CRM below).
Rules that also work in the source CRM
When you save a territory, TechieCRM also stores its rules in the source CRM's own form (a search catalog), so the source CRM's desktop applies exactly the same rules if anyone runs its Territory Alignment. The source CRM can only store some kinds of rule:
| Field | Conditions the source CRM can store |
|---|---|
| Country · State / Province · City · Zip / Postal Code · Address line 1 · Department · Division | begins with · contains · is empty · is not empty |
| Owner · Account Manager | is · is not · is empty · is not empty · is one of (only when it is the territory's only rule) |
| Name · Company (Firm) | none |
Why the gaps:
- The source CRM matches text by begins with. It has no exact is for a text field, so a rule such as State / Province is "BC" cannot be stored. State / Province begins with "BC" can, and for two-letter codes it usually means the same thing.
- The source CRM's "Company name" is a different column on a company than on an individual, so Name and Company (Firm) rules have no exact equivalent.
- A value containing
* % ? _ [ ](for Owner and Account Manager, only* % ?), starting with<or[, or longer than 120 characters is not stored, because the source CRM would read those characters as search instructions.
If any rule of a territory cannot be stored, none of them are: the territory keeps working in TechieCRM exactly as written, but the source CRM's desktop treats it as a catch-all. The edit window, the save message and the Description panel all say so, and name the rule to change. Nothing is stored that would make the source CRM apply a different rule.
Catch-all territories
A territory with no rules at all is a catch-all. During alignment it takes every entry that no territory above it has already claimed, and alignment stops there. Territories listed below a catch-all are never tested. The dialog says so in the rules box and in the Description panel; put your catch-all at the bottom of the list unless you mean to shut off everything under it.
Deleting a territory
- If no client entries carry the territory, you are asked to confirm, and it is deleted together with its rules and its stored copy for the source CRM.
- If entries do carry it, clearing them is a bulk change, so it goes through the same review screen as an alignment run: you see every entry that would be cleared and you approve it. If any entry fails to clear, the territory is not deleted.
- Once the territory is deleted, that clear cannot be undone: Undo last alignment… refuses to put entries back into a territory that no longer exists (they would show a blank Territory and the source CRM's alignment would never touch them again). If you may want the territory back, untick Active instead of deleting it.
Source CRM Catalogs… (territories saved before October 2026)
Territories saved before TechieCRM learned to store rules for the source CRM (2 October 2026) have rules in TechieCRM only, so the source CRM's desktop still treats them as catch-alls. The Source CRM Catalogs… button below the Setup buttons fixes that, safely:
- It first shows a dry run: every territory, what the source CRM makes of it today (Stored for the source CRM, Not stored yet, Cannot be stored, Source CRM copy differs, Catch-all in both, or Set up in the source CRM), and what would happen. Nothing is written.
- Write N catalogs stores the rules of every territory listed as Not stored yet. Each territory is written on its own; if one fails the others still go ahead, and the message names the one that failed.
- Cancel writes nothing.
A territory whose stored copy differs from its rules (someone may have edited it in the source CRM) is never overwritten by this button. Open it with Modify… and press OK to replace the stored copy deliberately.
Territories set up in the source CRM
A territory created in the source CRM's own desktop shows up here too. When TechieCRM can read its rules exactly, they appear in the Description panel and the edit window, and alignment uses them. When it cannot (for example a rule on a user-defined field), the Description panel says so, TechieCRM does not treat it as a catch-all, and Align Territories refuses to run while it is active (make it inactive, align it in the source CRM, or replace its rules here). Saving such a territory with no rules (for example to rename it) leaves the source CRM's rules exactly as they were.
The Alignment tab
Territory alignment conditions
Choose which client entries the run looks at:
| Condition | Meaning |
|---|---|
| Client entries created/modified since (date) | Only entries created or last modified on or after that date. This is the default; the date box is only live for this condition. |
| All client entries | Every company and individual in the database. |
| All entries in the Clients window | Only what the Clients list is currently showing (after a search or a favourite list). Greyed out when the Clients module is not open. |
| Selected entries in the Clients window | Only the rows you have highlighted. Greyed out when nothing is selected. |
Only companies and individuals are ever aligned. Contacts inside a company are never touched.
Options
- Unassign territories: instead of aligning, clear the territory from every entry in scope.
- Overwrite territories set by manager: an entry whose Territory Status is Set by Manager is protected: alignment leaves it alone and counts it under Skipped. Tick this to change those entries as well.
Align Territories
Align Territories does not write. It works out what would change and shows you a review window listing every affected entry: its name, its territory now, its territory after, and the status it would end up with. Nothing happens until you press Apply; Cancel leaves the database untouched.
When there is nothing to change, it tells you so and no review window appears.
Alignment results
After a run, the four counters report what happened:
| Counter | Meaning |
|---|---|
| Aligned | Entries given a territory by a rule, or dropped out of one because no rule matched any more. |
| Unassigned | Entries cleared by the Unassign territories option (or by clearing a territory before deleting it). |
| Skipped | Entries already correct, plus entries protected by Set by Manager. |
| Failed | Entries that could not be written. The message under the counters names the first few. |
Undo last alignment…
Every run records the previous territory, status and account manager of every entry it changed. Undo last alignment… puts them all back. The button is greyed out when there is no run to undo, and its tooltip names the run, who ran it and when. A run can only be undone once.
Undo refuses, and changes nothing, when any of those previous territories has since been deleted; the message names the territory. Re-create it and run Align Territories instead.
What a territory changes on a client entry
| Field | Set to |
|---|---|
| Territory | The winning territory's name (shown in the client's key fields). |
| Territory Status | Set by Rule when a rule matched · Unaligned when an entry lost its territory because nothing matched · Unassigned when it was cleared. The other two values, Set by User and Set by Manager, are written elsewhere in the CRM; alignment only reads them. |
| Account Manager | Only when the territory has exactly one account manager. |
Every entry alignment changes also has its last-modified date updated.
Where the information is stored
| What | Where |
|---|---|
| Territories, their order and their active flag | AMGR_Territory, the source CRM's own table |
| Account managers per territory | AMGR_Territory_Managers |
| Each entry's territory and status | AMGR_Client_Tbl.Territory_Id / Territory_Status (+ Assigned_To) |
| Alignment rules (as you wrote them) | TCRM_TerritoryRule |
| The same rules in the source CRM's form | AMGR_SearchCatalog (one row, type 11, described "Territory") + AMGR_SearchCatalogItem (one row per condition), linked by AMGR_Territory.Catalog_Id |
| Alignment runs and the undo history | TCRM_TerritoryAlignment / TCRM_TerritoryAlignmentItem |
The three TCRM_ tables are created automatically the first time you connect (or the first time
you open this window). If your database login may not create tables, ask an administrator to run
docs/db/territory/01_schema.sql once. Without those tables the territory list, Add, Modify,
Delete, Move and the alignment itself all still work; only the rules and the undo history
are unavailable, so every territory behaves as a catch-all.
If this database is also used by the source CRM's own desktop client, its Territory Alignment applies the same rules as TechieCRM for every territory whose Description says Stored for the source CRM. Check the Description (or Source CRM Catalogs…) before running it: a territory marked Not stored yet or Cannot be stored is a catch-all to the source CRM and would sweep every remaining entry into itself.
Shared with the TechieCRM cloud
Your territories are shared with the TechieCRM cloud, so the website can use them too. Web forms use them to choose who owns a new entry: when someone fills in one of your web forms, the cloud tests the address they typed (country, state or province, ZIP or postal code, city) against your territories in the same order and with the same rules as Align Territories, and gives the entry to the winning territory's account manager. If no territory matches, or the territory's account managers have no TechieCRM login, the form's own assignment setting decides.
What is shared, for each territory: its name, its place in the list, whether it is active, its rules (yours, or the source CRM's when it was set up there), and for each account manager: their source CRM user ID, their email in the source CRM and, when their TechieCRM account is linked to that user ID, their TechieCRM login email and the link itself (see Your two email addresses, and the link between your two user IDs in A3). Nothing about your client entries is sent by this.
- When it updates. Every time TechieCRM syncs with the cloud (every 15 minutes while the app is open, with cloud sync on), and straight away when you Add, Modify, Delete or Move a territory here. A territory you delete stays in the cloud marked as deleted, so it is never used again.
- An account manager is skipped on the website when the website cannot tell which TechieCRM user they are: their account is not linked to their source CRM user ID, and their source CRM email is not a TechieCRM login either. Linking the account fixes it whatever the emails are; otherwise give the user, in the source CRM's user setup, the email they sign in to TechieCRM with. (The website uses the link once its update for it is released; until then it matches the emails only.)
- A territory whose rules TechieCRM cannot read (set up in the source CRM with conditions it cannot express) stops the website from choosing by territory at all, exactly as it stops Align Territories here; the form's own assignment setting decides until you fix or deactivate it.
- Only workspaces connected to a source CRM database have territories. A cloud-only workspace has none, and its web forms always use their own assignment setting.
- The cloud starts using them once it has been updated to accept them. Until then nothing is sent, and nothing else changes.
Not yet available
- Setting a territory by hand on one client entry from the client dialog (status Set by User). Today a territory is assigned by alignment, and the client entry shows it read-only in its key fields.
- Rules on user-defined fields; the rule fields are the built-in address-book fields listed above.
- Multiple account managers written onto the client entry itself (see Account manager, above).
- Territory columns in the Clients list column setup, and territory-based reporting.