- to model out the location structure of a larger site
- i.e. Building, Floor and Room on different levels
- can also be used when not having a fixed location or location is frequently changing
- Assets and Locations can easily be moved or reparented (drag n drop) if their location changes
- Locations can be manually ordered by drag n drop
- can be Physical or Functional location
- available on mobile where technicians can add locations and assets
- Address in Work Order gets updated according to the Functional Location Address, or if this is empty, the system searches across all Parents Location’s addresses (on more than one level!), and takes these if found
- In Work Order form when first picking a Primary Incident Customer Asset, then the Functional Location gets auto-populated
- After creating a Work Order, the Primary WO Incident will also be related to the Functional Location chosen in the WO
- Creating a second WO Incident does NOT automatically relate the WO’s Functional Location to this 2nd WO Incident. Instead it can be manually set i.e. to another Functional Location (or create field mapping if you want it to be the same.)
Data Model of Functional Location
- possibility to add individual address which automatically gets geo coded
- 1:n Subgrids:
- Customer Assets
- Work Orders
- Work Order Incidents
- Agreement Booking Incidents
- native N:N relationship to Account
So if a User would want to track Work Order Products, WO Services, WO Service Tasks on it, the Functional Location is NOT the best table to use. This brings us to the decision that a HVAC Unit and its components like Compressor, Fan, Thermostat… are better represented as Customer Asset than as Functional Locations (see screen above and note the different symbols for Location versus Asset).
Why N:N relationship to Account?
Imagine you have a big campus and you have different Service Accounts responsible for managing Work Orders of different typesbe .
Or a big construction site with different subcontractors working on the same Functional Locations and Assets.
=> This helps to be flexible enough to have those Locations used be more than one Service Account.
To keep in mind with hierarchies and lookup prefilters here
Functional Location lookup field on Work Order
When creating a Work Order the Functional Locations are prefiltered to those of the Service Account.
Note: Creating a new Asset from the hierarchical tree view f the Account form automatically adds the Account to the created Asset.
However creating a new Functional Location from the hierarchical tree view does ONLY automatically ad the Account to the created Location if that is on the highest level directly under the Account.
When adding a Functional Location to a Work Order after the Service Account has been filled in, only those Locations are suggested by the OOB Lookup View that have the Service Account directly related or related to one of the parent Locations (also over more than one hierarchy level).
However if you’re either removing the Parent Location on the Location form or if you remove the Service Account from the N:N subgrid of the highest level Location, then your Locations won’t be found by the Functional Location Lookup view on the Work Order or Case form anymore. You would need to click Change View and then guess which Location was the one you needed.
I personally think it would be more convenient if Microsoft would automatically add the Account to all levels of Functional Location when created from Account form, as it does for the Customer Asset [improve@microsoft]. A user could still delete the Account from the N:N subgrid if not needed.
Until than it could be solved by a custom cloud flow.
Primary Incident Customer Asset lookup field on Work Order
When creating a Work Order the Primary Incident Customer Asset lookup is prefiltered by the Functional Location chosen before, but only for the Assets that are directly related to the Functional Location via ‘Customer Asset’.’Functional Location’ lookup, not for the Child Assets of such an Asset. Why? The child assets do not automatically inherit the Functional Location of the Parent Asset.
With the hierarchy above you wouldn’t find any Asset when chosing Basement and you would still not find Monitor 1 when chosing Room 005. However you can click Change View and remove this flag and then be able to get a list of all Assets of the Service Account:
Depending on your use cases you could surely also solve this by a custom process (Workflow/Flow) that updates the Child Asset’s Location to the Parent Asset’s Location each time there’s a change in the Asset hierarchy.
Customer Asset Form
In a Microsoft Video there is a Customer Asset Form visible in a browser that contains the new Functional Location/Asset-Hierarchy-View:
I wasn’t able to find this form in my latest OOB installation until I found out that I need the Security Role Field Service – Resource to be able to see the form Customer Asset – Mobile (below screenshot). Being “just” System Admin is not enough to get this form provided ;-).
Tip: As stated somewhere else in relation to WO Products and WO Services already, if you’re customizing Field Service, make sure to also assign yourself the other Field Service Security Roles available OOB. System Admin role does NOT provide you access to all the forms used in Field Service [improve@microsoft].
Here it is to mention that only those Assets are visible in the new hierarchy control if one of the parent Functional Locations is related to the Account AND the Top-Level Asset (aka Master Asset) belongs to the Account.
This could also be a little bit improved [improve@microsoft] so that also Asset Hierarchies/Assets are visible that have no Functional Location related to the Account but where only one of the parent assets or at least the Asset itself is related to the Account.
So if you use this feature on the Account form make sure to always add your Functional Locations to all necessary Accounts (n:n) and remember that Assets only show up on the Account form if the Master Asset belongs to the account.
Also remember, that on the Asset Form you might get a better overview of how the Asset in embedded in the Location/Asset structure.
Even if there are still some things to consider and improve, in general this is a very great addition to overall Field Service functionality as many Field Service organizations have a need for a deeper structuring of their locations. Servicing industry clients regularly needs more specific information for the field tech about where to go than simply the main Service Account address.
We even had a need to create graphical inhouse maps of floors and rooms to make transparent where exactly the work has to be done.
The much improved flexibility that comes with Functional Locations can be used for rental services or large machinery, which regularly change places (like construction machines, trains, ships, and similar).
Also I think the long standing problem of a Return & Repair process could be addressed with a Functional Location similar to a “Repair Warehouse”.
A great combination is the new ability to “Disable Customer Asset Validation” which turns off the necessity that a Customer Asset handled during a Work Order needs to belong to the Service Account of the Work Order.
18 Min. introduction Video by MS Field Service Team: https://www.youtube.com/watch?v=UCjyEKH0qFg
Our D365 Goddess Dian Taylor:
And of course Microsoft Docs (thanks to Dave Clark & Dan Gittler):