Asset hierarchies in Dynamics 365 Field Service

A wind turbine isn't one asset; it's a parent asset (the turbine) with sub-assets (gearbox, generator, blades, controller). A manufacturing line has multiple machines, each with components. A building has HVAC units, each with subsystems. Field Service asset hierarchies model these multi-level structures so work orders, maintenance, and analytics reflect operational reality.

The customer asset entity.

• Asset name and identifier — serial number, asset tag.
• Make, model, manufacturer — what it is.
• Customer — the owning organisation.
• Location — physical site.
• Parent asset — for hierarchy.
• Functional location — where it sits within the larger structure.

Hierarchy via parent asset.

• An asset's Parent Asset field points to its parent.
• Hierarchy navigable up and down.
• Multiple levels supported (no fixed depth).

A typical hierarchy:

Building 1
  Floor 2 HVAC
    Air Handler Unit
      Cooling Coil
      Heating Coil
      Fan Motor

Each is its own asset record; relationships build the tree.

Functional locations. Alternative organising structure:

• Functional location ≠ physical asset.
• Physical location structure ("Building 1 → Floor 2 → Room 203").
• Assets assigned to functional locations.

Some operations prefer functional location-based organisation; others prefer asset hierarchy. Both can coexist.

Asset categories. Type-based classification:

• Heating equipment.
• Cooling equipment.
• Plumbing.
• Electrical.

Categories drive default maintenance, default work order types, default service contracts.

Work orders on hierarchical assets.

• Work order targets a specific asset.
• Can also reference parent for context.
• Sub-asset failures may require parent-level diagnosis.

The hierarchy enables impact analysis — "if the gearbox fails, what else is affected?"

Maintenance plans. Per-asset or per-asset-category:

• Schedule routine maintenance.
• Generate work orders automatically.
• Each maintenance plan targets specific asset(s).

For asset hierarchies, decide which level maintenance plans attach to — typically the operating asset, not individual components.

Asset lifecycle states.

• Active — in service.
• Inactive — out of service but retained.
• Decommissioned — removed permanently.
• Under maintenance — temporarily down.

State transitions tracked; reporting respects state.

Asset attributes. Custom fields per asset category:

• Capacity.
• Voltage.
• Manufacturer-specific specifications.
• Last service date.

Stored as additional columns or as related attribute records.

IoT integration. Connected assets:

• Each asset has IoT device association.
• Telemetry data linked.
• Alerts trigger work orders.

The asset hierarchy informs alert routing — a sub-asset alert may escalate to the parent's responsible team.

Service contracts. Asset-linked:

• Coverage by asset or asset group.
• Different service levels per asset type.
• Renewal cycles per asset.

Tracking which assets are under contract is operationally critical for billing decisions.

Reporting hierarchies.

• Asset utilisation — by asset or by hierarchy parent.
• Maintenance cost — by hierarchy.
• Mean time between failures (MTBF) — by asset type.
• Mean time to repair (MTTR) — diagnostic effectiveness.

These metrics drive capital planning, vendor performance reviews, and operational decisions.

Asset transfers. When assets move:

• Customer sale of equipment.
• Internal transfer between sites.
• Re-deployment after maintenance.

Hierarchy and ownership must update; work orders in flight need handling.

Common pitfalls.

• Flat asset structure for complex equipment. Single asset record for what's actually multiple components; granularity lost.
• Over-decomposition. Every screw as separate asset; maintenance impossible.
• Hierarchy not maintained. Reality changes; system doesn't.
• Decommissioned not decommissioned. Inactive assets still generating false alerts.
• No standard category taxonomy. Each customer has unique categories; cross-customer reporting impossible.

Best practices.

• Hierarchy depth thoughtful. 2-4 levels usually enough; deeper rarely useful.
• Decompose to maintenance unit. What's separately maintained = its own asset.
• Consistent categories across customer base.
• Asset audit periodic — verify reality vs system.
• Decommissioning discipline — actively retire stale assets.

Service organisations' patterns. A typical maintenance services company:

• Tens of thousands of customer assets.
• Multiple sites per customer.
• Complex hierarchies for industrial equipment.
• IoT integration for monitored assets.

Field Service handles this scale with appropriate setup.

Operational rhythm.

• Per work order completion — update asset state.
• Quarterly — asset audit per customer.
• Annually — asset master cleanup and reconciliation.

Strategic positioning. Asset hierarchies are foundational for serious field service operations. A flat asset model works for simple equipment; complex industrial environments demand hierarchical modelling. The investment in upfront hierarchy design pays back in work order accuracy, maintenance effectiveness, reporting clarity, and the ability to use IoT meaningfully. Field Service supports the depth; the organisation must apply the discipline to use it.