Almanac
Microsoft/d365fsDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Field Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across work orders, scheduling and dispatch, resource management, mobile app, asset management, inspections, IoT, Copilot, and administration.

feature-customer-assets-and-hierarchies.mdv1 · history
CurrentApplies to Field ServiceUpdated 6 days agoSource Microsoft Learn

What it does

A customer asset is a record of one piece of equipment sitting at a customer site that you inspect, maintain or repair. Assets can be nested — a parent asset with sub-assets — so a chiller, its compressor and the compressor's control board are three linked records. Every work order that touches an asset stays attached to it, which is what gives you service history.

Key facts

  • The table is msdyn_customerasset. A record needs a Name and, in practice, an Account — the service account representing the site. Everything else (Category, Product, Functional Location, Parent Asset) is optional.
  • Hierarchy is done with the Parent Asset lookup, with the Sub Assets grid showing children. Depth isn't capped in the docs; sanity is the only limit.
  • Assets can be created three ways: manually, bulk-imported from Excel (minimum columns Name and Account; Product and Functional Location values must already exist), or generated automatically from work order products.
  • Auto-creation is switched on per product: open the product, Field Service tab, General section, set Convert to Customer Asset to Yes. The asset appears when the work order product line status is Used and the work order reaches Open - Completed or Closed - Posted.
  • That auto-creation makes exactly one asset per product line regardless of the quantity on the line. Quantity 10 gives you one asset, not ten.
  • By default the asset lookup on a work order only shows assets belonging to that work order's service account. The Disable Customer Asset Validation setting (Settings > Field Service Settings, Work Order / Booking tab) lifts that filter.
  • Its companion, Suggest Reparenting Customer Assets, offers to change the work order's service account to match the account on the asset you picked. Microsoft's guidance is to turn both on together.
  • Service history is assembled from work order incidents and agreement incidents. Put the asset on the incident and Field Service stamps it onto the products, services and service tasks that incident generates.
  • One asset can have many IoT devices attached (a thermometer and a hygrometer on the same unit). The Check IoT Setup button on the asset shows deployment status and registered devices.
  • Knowledge articles can be linked to an asset record, which is the cheap way to get manuals and known-fix notes in front of a technician.

When to use / skip

Use customer assets when the unit of service is a thing rather than an address: serialised equipment, anything under a maintenance agreement, anything where "what did we do to this last time" is a real question. Lifts, HVAC, medical devices, coffee machines, generators — all obvious.

Skip, or at least go very light, if you're doing address-based break-fix with no repeat-equipment concept, or if the client can't tell you today how they identify a unit in the field. An asset register nobody can match to physical kit is worse than no register — technicians will create duplicates on every visit and the history fragments. Also resist the urge to make every replaceable part an asset. If you'd never raise a work order against it on its own, it's a property or a work order product, not an asset.

Configuration decisions

  • Where the asset boundary sits: what is an asset, what is a sub-asset, what is just a property on the parent. Get this wrong and either the hierarchy is unusable or the history is too coarse to be worth anything.
  • Whether assets are anchored to the account alone or to the account plus a functional location. Multi-building customers almost always need locations; single-site customers usually don't.
  • The asset category taxonomy, because categories are what property templates hang off. Decide categories before you design properties.
  • How assets get created in production: bulk import from the client's existing register, auto-conversion from work order products, or technicians creating them on mobile. Most projects need two of the three, and you have to decide which is authoritative.
  • Naming and identity — serial number, customer's own tag, or a generated ID — plus whether you set an alternate key on the table so re-imports update rather than duplicate.
  • Whether Disable Customer Asset Validation goes on. Rental, leased and managed-equipment models usually need it; a straight servicing business usually doesn't.

Gotchas

  • Convert to Customer Asset ignoring quantity catches nearly everyone. If the client sells and installs ten identical units on one work order, they'll get one asset and a puzzled look. Either split the lines or handle creation another way.
  • An asset's account is not a casual field. Moving equipment between customers properly is an RMA with the Change Asset Ownership processing action, not an edit — and if you do edit it, existing work order history stays put but the validation filter starts hiding the asset from the old account.
  • If you drag a sub-asset under a new parent that sits in a different functional location, the sub-asset adopts the new parent's location without asking. Assets that appear to have teleported usually got reparented.
  • Excel import skips duplicates by default. That sounds helpful until a migration silently drops 4,000 rows because the client's names aren't unique. Check the import job result, don't just check the row count you sent.
  • Assets created on mobile are only as good as the offline profile. If Customer Asset isn't in the profile with the right filters, technicians get an empty lookup in a basement and create a new asset instead.
  • Service history only builds properly when the asset is on the incident. Assets attached loosely to the work order header, or picked on a single product line by hand, give you a much thinner history than the client expects.

Consultant notes

  • Demo the asset form's service history and sub-asset tree early. It's the part of Field Service that sells itself, and it flushes out the client's real hierarchy assumptions in about ten minutes.
  • Agree the identity rule before any data work — serial, tag, or generated. Ask what a technician physically reads off the equipment. If the answer is "nothing, they just know", you have a data problem, not a config problem.
  • Push back hard on migrating a spreadsheet asset register without a dedupe pass. It is much cheaper to argue about 300 duplicate rows now than to reconcile them across live work orders in month four.
  • Before go-live, run through the cross-account scenario with the client even if they say it can't happen. Someone always sells a building.

Worth another look if the client moves to a rental or managed-equipment model, or if asset auto-creation behaviour changes in a future wave.

Was this accurate?