Introduction
Please note: this is a repost in the FSM Community from the original develop blog.
Field Service Management has an awesome functionality called Territory Planning that allows the careful planning of locations and their associated resources and work. It allows great insights into how much resources are available and needed in areas in order to optimize scheduling. However, what are our options for mapping locations to territories?
With Territory Planning turned on, each Work Order Task will have an additional field "Territory" in addition to the assignment group, which is automatically populated based on the geocoordinates of the Location added to the WOT. In this blog, we will explore a few options to assign locations to territories:
- Using the Territory Planning console to draw polygons on a map manually
- Importing GeoJSON
- Matching attributes
- Using the m2m table Territory Locations
Our Territory Planning console showing two territories and a bunch of markers for our resources and tasks
GeoJSON - drawing boundaries on the map
As per the ServiceNow documentation's section on Configuring Field Service Territory Planning > Creating geographies, one of our primary options for mapping locations is by drawing polygons on the map in the Territory Planning console in order to define boundaries.
This option is well-documented in the official documentation and therefore I will not go into this option much deeper. With these boundaries drawn, locations can be mapped in a geofencing type of way to their respective territories.
GeoJSON - Importing or via Integration
Drawing boundaries via shapes on the map, as per the above section, creates a GeoJSON at the end. Therefore, one of our other (undocumented) options is to simply directly input the GeoJSON into the Territory Geography's `geojson` field.
The GeoJSON field contains an entry with type FeatureCollection that has `features`, each of which are Feature objects with specific properties and geometries. This is all according to the GeoJSON format. There are numerous sources out there that provide GeoJSON data, both free and paid, for various groupings of locations, such as counties, post codes, etc.
This data can be obtained, manipulated and grouped as necessary, then imported via a regular data source + transform map, to be inserted into the Territory Geography's `geojson` field.
Alternatively, this could be done via integration. We saw one integration where the Territory Geography table was extended with a custom field listing specific properties, and an integration calling an API with a specific query for each of those properties to build a GeoJSON consisting of the appropriate polygons.
Matching attributes
Like drawing polygons on the map, Matching Attributes are well-documented in the official ServiceNow documentation under Configuring Field Service Territory Planning > Creating geographies > Create a matching attributes geography.
This will allow us to select matching attributes such as ZIP, City, State or Country. For ZIP, it is also possible to select a range.
Please note that with matching attributes, there are no polygons to be displayed on the map. Therefore, as a trade-off, less information is visually shown in the Territory Planning console.
Creating Territory Location entries
Territory Planning leverages an m2m table called Geography Locations [sn_tp_geography_location] that links Location [cmn_location] records to Territory Geographies.
For one customer, we had a requirement to link locations to territories according to a more refined ZIP search. Specifically, we looked at the first 3 digits of a ZIP code, corresponding to the the larger ZIP code area. Out of the box, this is not supported, and it was not feasible to import and maintain all variations of those ZIP codes using the regular matching attributes.
We looked at customizing Territory Planning's matching attributes logic itself, but found the technical debt not to be worth it. In the end, we opted for a different approach, namely building a Decision Table that maps our greater ZIP areas to Territory Geographies. We then built a business rule on cmn_location entries that creates, updates or deletes the corresponding m2m entries. This would mean a Geography Locations record was created for each cmn_location, which then allowed our locations to be properly looked up to their respective territories.
It's not difficult to imagine the use of a flow or business rule to automate any other logic to create Geography Locations for specific needs.
By using the Geography Location m2m table no specific shapes/polygons are known, therefore these groupings are not shown visually in the planning console, similar to matching attributes.
Conclusion
In conclusion, we have listed a number of ways to map Locations to Territories depending on the need. We can draw shapes on a map, import GeoJSON manually or automatically, use matching attributes based on location data, or even any custom logic.
Mapping locations to territories are just one aspect of Territory Planning, but an important one that we have gotten quite some questions on -- I hope this article clarified some common and flexible ways to approach this for your situation.
