Route work orders to Service Territory using mapped ID or name values in connector payloads.
Service Territory mapping allows external systems to route work orders to defined geographic areas. This data is exchanged via the Overview object in the work order details and is sent under dispatch.values as shown in the example below.
Integration Capability: Two dedicated mappable fields allow external systems to programmatically send the Service Territory information either during the work order creation or after the work order is created. These configurations are bidirectional.
A valid Break-fix Project must be associated with the work order to map a Service Territory.
Both fields are strings. The two mappable fields introduced are:
Prop
Type
Description
service_territory_id?string (UUID)The unique UUID of the service territory. Determines which geographic pool of providers is eligible for the work order. Obtain from the territories list in your connector configuration.
service_territory_name?stringExact display name of the territory as configured in Field Nation. Used as a fallback lookup when the UUID is unavailable. Must match the name exactly — partial matches are not supported.
{
"dispatch": {
"values": {
"service_territory_id": "839eca8c-ee08-4e9e-b568-584baae1997a",
"service_territory_name": "Greater Minneapolis East"
}
}
}Send service_territory_id, service_territory_name, or both values in the dispatch.values payload to map routing context.
The integration uses non-blocking validation. If the Territory logic fails, the work order is created without the Service Territory mapping, and an error message is returned.
Last updated on