Territories and resource territory coverage

What it does

A territory is a named geographic region used to divide the business for scheduling and reporting. Resources are linked to territories through a junction record so an engineer can cover several; customer accounts get a single service territory; the schedule board, schedule assistant and Resource Scheduling Optimization all filter on it.

Key facts

Territories are set up under Field Service > Settings > General > Territories. Only Territory Name is required; Manager and Parent are optional.
The Parent field gives you a hierarchy, so you can nest regions inside a country and areas inside a region.
A bookable resource can belong to many territories. The link is a Resource Territory record, created from the resource's Related > Resource Territories.
An account has one service territory, set in the Servicing section of the account form. That asymmetry — many for resources, one for customers — is the whole design.
Postal codes can be related to territories. Where a postal code exists on an account or work order address, the territory is populated automatically. See postal codes.
The schedule assistant filters resources by the requirement's service territory by default, so a resource with no territory record often just doesn't appear.
Schedule board tabs carry their own territory filters and can be saved as default so a dispatcher lands on their own patch.
Apply territory filter to requirements sits in Scheduler settings > Board view settings and filters the requirements pane, not just the resource list. Those are two different filters and people conflate them.
Territories are not exclusive to field work — a resource requirement carries a territory lookup, so the same regions can drive non-field scheduling scenarios.
For crews, the crew header shows on the board when it matches the territory filter, and crew members show regardless of their own territory assignment.

When to use / skip

Any organisation with more than one depot or more than about twenty engineers wants territories, because without them the board is one enormous unusable list and the assistant returns half the country for every job. The real question is not whether but how granular.

The trap is treating territories as pure geography. They are a filter, so they can encode anything the dispatcher wants to slice by — "Manchester" is a territory, but so is "Manchester - Gas" if gas and electrical dispatch are separate desks. That is a legitimate pattern and Microsoft documents it. It is also how you end up with four hundred territories nobody maintains. Skip the sub-division unless there is a named person whose job depends on it.

Skip territories entirely only for genuinely small, single-site operations — a workshop with eight staff and no field work gets nothing from them.

Configuration decisions

Granularity: country, region, city, or region plus purpose. Decide before data migration, because it drives the territory value on every migrated account.
Whether to build a hierarchy at all. Parent territories help reporting but do not cascade filtering the way people assume.
Whether territory on accounts and work orders is populated by postal code mapping or set manually. Postal code mapping means owning a postal code table.
Overlap policy for resources: is every engineer in exactly one territory with cross-border work handled as an exception, or are they in several by default?
Who owns territory maintenance after go-live — new postcodes, boundary changes, depot moves.
Whether Resource Scheduling Optimization scopes its scheduling runs by territory, which usually means territories and RSO scopes have to line up.

Gotchas

A resource with no Resource Territory record silently drops out of assistant results whenever the requirement has a territory. It is not an error, it is an empty list.
The territory filter on the board and the territory filter on requirements are separate settings. Turning on one and expecting both is a common support call.
Resources covering different territories at different times of year is not supported natively. Microsoft's guidance is a custom workflow. If the client has seasonal coverage, price it.
Territory is a lookup on the account, so migrated accounts arriving without one produce work orders whose assistant results ignore territory filtering entirely.
Postal code auto-population only fires when there is a matching postal code record. Partial or mistyped postcodes fail quietly and leave the field blank.
Renaming a territory is fine; deleting one is not, because saved board tabs, RSO scopes and views reference it and will not warn you.

Consultant notes

Ask to see the client's existing dispatch spreadsheet before designing territories. The regions they already use informally are almost always the right answer, and arguing for a tidier scheme rarely survives contact with the dispatchers.
Demo the saved board tab per territory. That single feature is what makes a multi-region dispatch team believe the tool is usable.
Push back on territory-as-skill. If the reason for "London - HVAC" is capability rather than geography, characteristics are the right mechanism and territories are not.
Check the postal code table's coverage before go-live if you have committed to auto-population. Partial coverage is worse than none, because it looks like it works.
Confirm every active resource has at least one territory record as a go-live gate. It is a two-minute FetchXML check that saves a bad first week.

Worth another look if Microsoft ever supports time-bound territory coverage without custom code.