Service Territory polygons in Salesforce Field Service look like a five-minute job. Open the Dispatcher Console, draw a shape on the map, link it to a territory, save. Done. Six months later the same polygons are silently routing appointments to the wrong territory, splitting jobs across time zones, and giving you "no resources available" errors that make zero sense. This post is the short list of things you wish you'd known before drawing the first one — the architect-level gotchas that don't show up in the help docs until you've already tripped over them.
What polygons actually do (and don't do)
Polygons live on the standard MapPolygon object. You can draw them in the Field Service map, or import them in bulk from a KML file — and most teams do, because hand-drawing two hundred postcodes is how junior consultants get paged at 11pm. Each polygon links to a Service Territory.
Here's the architect-level distinction most teams miss: polygons drive auto-assignment, not scheduling. Drawing a polygon doesn't tell the engine who can work in that area. It tells the engine which Service Territory an appointment should land on, based on the appointment's geocoded location. Who actually gets dispatched is still decided by your Work Rules — Match Territory and Match Territories — plus Operating Hours and Shifts. Two completely separate concerns share the word "territory," and confusing them is where most polygon problems start.
Match Territory vs Match Territories — the work-rule trap
These two work rules sound interchangeable. They're not, and confusing them has tanked more go-lives than it should have.
- Match Territory is the hard boundary. It matches
ServiceAppointment.ServiceTerritoryIdtoServiceTerritoryMember.ServiceTerritoryId. Same ID or no schedule. - Match Territories (plural) is the soft version. It lets a technician with both primary and secondary territory memberships pick up work across either.
The non-obvious gotcha: Match Territory ignores territory hierarchy. Even if your Service Territories are nested — Central London inside Greater London inside UK — the work rule does a flat ID match. A technician at the Greater London level cannot auto-pick up a Central London appointment, because the IDs don't match. The hierarchy is purely structural; the scheduling engine doesn't roll up.
If you want a technician to cover both levels, they need explicit Service Territory Member records at each level — or a Match Territories rule on the policy with secondary memberships configured. Pick the wrong work rule for your operating model and your most experienced technicians get locked out of half their work.
The single-territory return problem
Auto-Assignment takes the geocoded location of an appointment, runs a point-in-polygon check, and returns one Service Territory. One. Even if four polygons cover the same point.
This catches teams whose territories are functionally distinct but geographically overlapping — for example, "Boston Gas" and "Boston Electric" covering the same downtown blocks for the same utility. Out of the box, the system picks one based on your hierarchy policy and the other silently never sees the appointment. The dispatcher manually reassigns it once they realise. Repeat several hundred times a week.
The escape hatch is the FSL.PolygonUtils Apex class, which exposes a method to look up a Service Territory by latitude/longitude — you can call it from a Flow or trigger and build the multi-territory routing yourself. If your business has overlapping territories, plan for the custom code at design time, not at week six of go-live when someone notices half the gas jobs are landing on the electric crew.
The Lowest vs Highest hierarchy decision
When polygons nest — Central London inside Greater London inside UK — Auto-Assignment lets you choose whether the lowest or highest territory in the hierarchy wins. Lowest routes to the most specific territory. Highest pushes everything up to the broadest one.
The trap: it's a global setting. You can't mix. Pick "Lowest" because the Central London team owns Central London, and a UK-wide territory you actually wanted to dispatch from goes quiet — every appointment routes to the smaller polygon underneath it. Pick "Highest" and your local crews never see the local jobs.
The fix is to design the hierarchy itself around the policy choice. If your operating model is local-first, use Lowest and don't create overlapping higher-level territories that you expect to dispatch from. If it's central-first, use Highest and treat lower-level polygons as visualisation only. Either way, the choice happens once and lives forever.
The time zone trap
This one bites hard because the symptoms show up downstream of the cause. The Operating Hours record that carries a Service Territory's time zone hangs off the territory itself. If your polygon spans two time zones — and plenty of US, Canada, and Australia regions naturally do — the OH evaluation is correct for half the area and one hour off for the other half. Shifts, optimisation windows, SLA clocks, customer notifications: all wrong on one side of the line.
The architect-level rule: Service Territories must not cross time zones. Split the polygon at the zone boundary and create two territories, even if the business thinks of it as one region. The territory boundary buys you correct OH evaluation. You can still roll the two up for reporting.
The sharing trap
Service Territories drive object sharing in Field Service. Once a territory exists with appointments and resources hung off it, retrofitting your sharing model is brutal. The fix: set Org-Wide Defaults for Field Service objects to Private and design sharing — territory hierarchy, STM rules, manual sharing exceptions — before the first polygon is drawn. Most teams skip this because it's a "nice to have" until production data arrives and the rework becomes a multi-week project.
Geocoding silently kills the match
Auto-Assignment is a point-in-polygon check. No point, no match. If the appointment's address fails to geocode — bad postcode format, ambiguous match, geocoding queue backlog — the territory assignment quietly skips. The appointment lands without a territory, and unless you have a validation rule blocking that state, the next dispatcher just sees "no candidates available." Always wire the geocoding status into your appointment lifecycle so a failed geocode escalates loudly instead of disappearing.
The takeaway
Polygons are deceptively simple to draw and deeply load-bearing in production. The decisions you make at design time — hierarchy direction, time-zone splits, overlapping territory strategy, sharing model — are the ones you live with for years. At Fynaxis, we run a Polygon Audit as part of every Salesforce Field Service health check. If your dispatch console is making territory decisions nobody can explain, this is almost always where it starts. Get in touch.