What it does

Inspection templates are drag-and-drop digital forms that a technician fills in as part of a work order. You build them in a designer under Settings > Work Orders > Inspection Templates, and the questions live as JSON on a version record rather than as Dataverse columns, so adding a question doesn't touch the schema.

Key facts

• The template record is msdyn_inspection; each saved set of questions is a separate msdyn_inspectiondefinition (Inspection Template Version) record holding the questions in msdyn_JsonContent, capped at the standard memo limit of 1,048,576 characters.
• Question types in the toolbox: Textbox (single or multiline, with a read-only option), Checkbox (multi-select), Radiogroup, Dropdown, Entity Lookup, Number, Date Time, File, Barcode Scan, and a dynamic Matrix that lets the technician add rows.
• Entity Lookup questions query real Dataverse records, respect the answering user's security roles, and support filtering — this is the only question type that gives you referential answers rather than free text.
• File questions accept gif, bmp, jpeg, jpg, png, mpeg, mp3, mp4, wav, mov, pdf, doc, docx, xls, xlsx, ppt, pptx, txt and log. The default per-file cap is 3 MB unless the organisation's attachment size limit has been raised.
• Questions are grouped into Pages. Under Advanced you control whether the title and description show, whether question numbers show, and the layout density: Comfortable (answer under the question) or Compact (answer to the right).
• The template Name cannot be changed once the template is published.
• Preview inside the designer renders the form as the technician sees it, including logic, before you publish anything.
• Export to JSON exists for moving templates between environments; Export to PDF produces a blank printable form, and interactive question types such as Entity Lookup won't function in the PDF.
• A Copilot-assisted flow that converts an uploaded PDF or photo of a paper checklist into a draft template exists but is in preview and was tested against English forms only.

When to use / skip

Use inspections whenever the field answer set is structured, repeatable, and you want it queryable afterwards — safety sign-offs, pass/fail asset checks, commissioning sheets, regulated audits. They are considerably faster to author than a custom entity plus a mobile form, and they work offline in the mobile app without you building anything.

Skip them when the technician only needs a tick-list of steps with no captured data: plain work order service tasks already do that, and every inspection you add is another version record and another chunk of JSON to deserialise. Also skip when the answers must drive validated, relational business logic in near real time — the answers arrive as JSON and get parsed asynchronously, so if you need a strongly typed field the moment it's saved, model it as a real column on the work order or the asset instead. And if the form is really a customer-facing questionnaire rather than a technician task, Customer Voice is the better fit even though inspections happen to store their parsed answers in the Customer Voice tables.

Configuration decisions

• Which forms genuinely need to be inspections versus plain service tasks, and which need to be real Dataverse fields because downstream logic depends on them.
• Naming convention for templates, decided before the first publish — the name is fixed afterwards, so bake in asset family or region if you'll ever need to distinguish.
• Whether to use one large template with pages and branching, or several small templates attached to separate service task types. Small ones are easier to version; large ones are fewer clicks for the dispatcher.
• Whether any question needs to be an Entity Lookup, and if so what the filter is and whether every technician's security role can actually read the target table.
• Layout density and question numbering — trivial to change, but agree it once so all your templates look the same on a phone.
• Whether attachments are expected, and whether the 3 MB default is realistic for the photos your technicians take on modern handsets.

Gotchas

• Don't export a template to JSON and re-import it unchanged into the same environment. The out-of-the-box deserialisation flows choke on it and you get failures that are awkward to diagnose.
• A trailing page with no questions on it causes deserialisation errors. Delete empty pages before publishing.
• The template name being immutable after publish catches people out constantly, usually after someone publishes "Test 1" during a demo and it becomes the production template.
• Entity Lookup questions look fine in the designer for an admin and return nothing for a technician whose role can't read the table. Test lookups with a real Field Service - Resource role, not your own.
• A work order service task holds a single inspection response. Clearing responses to redo an inspection deletes the original answers rather than versioning them.
• Attachments captured in inspections land as notes, and a dispatcher without delete privilege on the Note table can clear all attachments but cannot remove an individual one.

Consultant notes

• Demo the designer live to the client's process owner. The drag-and-drop build is the single most convincing thing in the module and it usually kills the "we'll need custom development for our forms" objection in one meeting.
• Push back hard on lift-and-shift of paper forms. Clients arrive with 40-question A3 sheets; on a phone in the rain that's abandonment. Split by page, use branching, and cut anything nobody reports on.
• Agree ownership before go-live. Templates are an admin function, and the client's process owner needs a named person who can revise and republish without raising a change request each time.
• Check the attachment size limit and mobile storage assumptions during UAT, not after — photo-heavy inspections are where offline sync complaints start.

---

Worth another look when the Copilot template generation leaves preview, or if Microsoft adds question types beyond the current toolbox.