Functional Locations

Note: This is a preview feature; part of 2020 Release Wave 2.

Imagine we are implementing Dynamics 365 Field Service for facilities management of a residential complex. The complex includes a couple buildings, park, swimming pool etc. Our client manages all the electrical and mechanical aspects of all the assets. Now as the project commences, one of first few things we would like to figure out will be the structure of Service Accounts and Asset.

Photo by Aksonsat Uanthoeng on Pexels.com

Client’s asset register looks like below for 2 lights installed in different buildings:

AssetParent (asset)LocationParent (location)
Light 0343Lights panel 1243Floor 5Building A (32-A Atlantis Street)
Light 2340Lights panel 9920Floor 5Building B (32-B Atlantis Street)

Taking out our 3-D glasses, we can see that each asset lives in three distinct dimensions:

  1. Fundamental features: Asset’s name, type and Location
  2. Asset’s position in the hierarchy of Assets. For example, an individual light is part of lights panel, WiFi router is part of a network
  3. Asset’s position in the hierarchy of Locations. For example, an asset is in room 5 of floor 5 of building B

Above 3-dimensional information is important for Field Technicians (Bookable Resources) to service Assets to arrange access, understand how fixing a part will impact parent asset, analyze the impact of asset servicing on location hierarchy etc. A simple example of this analysis is to be able to notify all the residents on the impacted floors who will experirence an outage while fixing a particular asset.

Now if we look at Dynamics 365 Field Service in the current world, the only entity that derives location is Service Account. Service Account serves (at least) two purposes:

Service Account = Location/address of service + Account that is being serviced

Assets can be linked (optionally) with Service Account but this leaves all three dimensions disjointed.

Introducing Functional Locations

The Dynamics 365 Field Service team has resolved this challenge by introducing two changes:

  1. Functional Location entity
  2. Functional Location control

Let’s unpack Field Service (out of the box / off the shelf) to look at these two shiny brand new changes:

Functional Location Entity

Functional Location basically disjoints the ‘location’ with ‘address’ and makes ‘location’ an attribute which can be linked with Assets, Work Orders, Work Order Incidents, Cases etc. Comparing to the above “Service Account” – centric design, the introduction of Functional Location changes the design of Field Service to have these revised definitions of entities:

Service Account: Account that is being serviced
Functional Location: Location of the service

Another interesting property of Functional Location is that it is in itself a hierarchical entity which means Functional Location can have a parent Functional Location, so if a child is missing an address, the system can fetch the address of the parent. Example of this scenario are floors and rooms in a building as they will all have one address on the map but functionally they will be structured as a hierarchy.

Functional Location Control

The other major innovation related to Functional Location is this new control which you can find on Assets, Accounts and other entities.

I am truly impressed with software engineering here, the control:
1) lets you see both functional locations and assets
2) add assets
3) edit assets
3) change hierarchy by dragging and dropping assets and functional locations

The control features a truly modern 2020 experience!

How does this impact Solution Design

In the current world, for the above scenario, we will need to create multiple Service Accounts for each asset having a different address. Once Functional Location feature becomes generally available, we will need just one Service Account, a hierarchy of Functional Locations, and then tagging assets per functional location. From the aesthetics, database normalization and even dictionary meanings of ‘Service Account’, ‘Functional Location’ etc., this new design looks very neat, clean and easy to maintain.

Impact on current implementations

It would be unfair to close this article without complementing the product development team. This change, in the Service Account area, is an excellent example of “defensive programming”. It is lean in terms of database model changes and impact on UX is minimal (only one control is smart enough to be used in multiple entities and interact with multiple entities).

Thanks for reading!

I’d love to hear your thoughts 🙂