Choosing how deep to model assets and functional locations

What it does

Field Service gives you two nestable structures for describing the physical world: customer assets, which nest through a Parent Asset field, and functional locations, which nest through Parent Functional Location. Assets are the things you service; functional locations are the places those things sit. The decision is how many levels of each you actually build, and it's one of the few modelling choices on a Field Service project that is genuinely expensive to reverse.

Key facts

Functional locations form a place hierarchy — campus, building, floor, room — and an asset can be associated with one. The association is optional.
Assets inherit the functional location of their parent asset. Move a sub-assembly's parent from Building A to Building B and the child follows.
A subcomponent of an asset cannot be assigned to a different functional location from its parent asset. If a component genuinely lives somewhere else, it isn't a subcomponent.
On the work order, functional location sits on the General tab under Location. If it's blank, the system falls back to the service address on the work order, then to the address of the reporting contact.
Different incidents on the same work order can carry different functional locations, so one visit can legitimately touch several places on a site.
Products can auto-create customer assets: set Convert to Customer Asset to Yes on the product's Field Service tab, and an asset appears when the work order product's Line Status is Used and the work order reaches Open-Completed or Closed-Posted. One asset per product line regardless of quantity — this catches people out with consumable quantities.
Auto-creation works for products only, not services.
Asset validation is on by default: only assets related to the work order's service account can be selected. It's a setting, and switching it off matters for multi-site customers.
Microsoft doesn't publish a hard depth limit for either hierarchy. Treat performance and usability as the limit.

When to use / skip

Most projects overbuild this. The honest test is: at what level does a work order get raised, and at what level does someone ask "when did we last touch this?" Model to that level and one below it, and stop. If nobody will ever raise a job against a floor, a floor is not a functional location — it's a text field on the asset.

Deep asset hierarchies pay for themselves in three situations. Serialised equipment with serviceable subcomponents where warranty and replacement history is tracked per part — lifts, MRI scanners, HVAC plant, production lines. Regulated estates where an inspection record must attach to a specific component. And anywhere parts get swapped between parent units and the history has to travel with the part, not the machine.

Functional locations earn their place when the customer is a site rather than a company: hospitals, universities, airports, shopping centres, social housing. If the typical customer is an account with one address and one boiler, functional locations are ceremony — use the service account and the service address.

What I'd actually do on a mid-size project: two or three asset levels maximum, functional locations only if the client has multi-building sites, and asset categories used properly from day one because they're cheap and they carry the reporting. Adding a level for one customer segment in phase two is manageable. Restructuring a hierarchy that already carries five years of work order history is not.

Configuration decisions

Decide the level at which work orders get raised. That's your minimum modelled level and it dictates everything downstream.
Decide whether functional locations exist at all. If yes, agree the naming convention and the number of levels before anyone creates a record — inconsistent naming is what actually kills these hierarchies.
Decide whether asset validation stays on. Turning it off widens the asset picker for multi-site and landlord scenarios but removes the guard against booking work against the wrong customer's kit.
Decide which products auto-create assets. Be selective: every product with Convert to Customer Asset set to Yes will quietly generate records forever.
Settle asset categories and property templates early, because retro-applying properties to an existing asset estate is a data project.
Decide how assets get created initially — import, migration from a legacy asset register, or discovered by technicians over the first year of visits. All three are legitimate; the third is often the honest answer.

Gotchas

Reparenting assets moves their functional location silently. That's correct behaviour, and it surprises people the first time an entire sub-tree relocates.
You cannot split a component away from its parent's functional location. Teams model "the pump is in the plant room, its controller is in the office" and then discover the structure won't allow it.
Auto-created assets ignore quantity — fitting twelve identical valves gives one asset unless you split the lines. Services never auto-create assets at all.
Asset validation being on by default means a technician at a tenant's site can't pick the landlord's asset. This surfaces during UAT, usually loudly.
Deep hierarchies make the asset tree slow and the mobile experience worse. The mobile app's location and asset hierarchy views want connectivity, so a deep tree is exactly what a technician can't browse in a basement.
There's no supported bulk restructure. Fixing a badly designed hierarchy means scripted updates against msdyn_customerasset with the history attached.

Consultant notes

In the discovery workshop, ask the client to draw one real site on a whiteboard, then ask which boxes they'd raise a job against. Everything they don't point at is a candidate for deletion from the model.
Demo the asset tree and the work order's asset lookup together. Clients only understand the cost of depth when they see the picker.
Push back on importing the whole legacy asset register on day one. Import the assets that will get work in year one; let the rest arrive when they're touched.
Warn the client that hierarchy design is effectively permanent, and get sign-off on the level structure as a named decision rather than burying it in a design document.
Before go-live, spot-check that auto-create is set only on the products you intended, and count the assets UAT actually generated.

Worth revisiting if Microsoft publishes depth or performance guidance for asset trees, or if the mobile asset hierarchy gains proper offline support.