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.
Client’s asset register looks like below for 2 lights installed in different buildings:
| Asset | Parent (asset) | Location | Parent (location) |
|---|---|---|---|
| Light 0343 | Lights panel 1243 | Floor 5 | Building A (32-A Atlantis Street) |
| Light 2340 | Lights panel 9920 | Floor 5 | Building B (32-B Atlantis Street) |
Taking out our 3-D glasses, we can see that each asset lives in three distinct dimensions:
- Fundamental features: Asset’s name, type and Location
- 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
- 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:
- Functional Location entity
- 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 🙂