Choosing inspections or custom tables for structured capture

What it does

Inspections are Field Service's built-in digital forms: an administrator designs a question set, publishes it, attaches it to a work order through a service task or an incident type, and the technician answers it on the mobile app — offline included. The alternative is modelling the same capture as real Dataverse tables and columns with a normal form. The decision is which of your structured capture goes through inspections and which gets first-class schema, and getting it wrong hurts on the reporting side rather than the delivery side.

Key facts

Inspections are designed in a drag-and-drop designer, published, and consumed on work orders via service tasks. They can also be used without work orders, against customer assets.
Answers are stored in Dataverse, so they're reportable — but through the inspection response tables (msdyn_inspectionresponse, msdyn_inspectioninstance), not as columns on the work order.
A published inspection is read-only. To change it you use Revise, which creates a new draft version.
Publishing a revision replaces the original. Previous versions aren't retained as separate records you can go back to.
Existing service tasks keep the inspection version that was current when they were created. Revising doesn't retro-fit in-flight work — which is correct, and also means a work order raised last month answers last month's questions.
Branching is supported: make a page visible, show a question, change a question to required, or skip to a question, all driven by earlier answers. A question's visibility maps to a single rule, though a rule can hold multiple conditions.
Inspections can be exported and imported as JSON for moving between environments — that's your ALM route, and it's separate from the solution.
Responses export to PDF for sharing, but PDF export doesn't support custom date or number formats, right-to-left languages, Hindi, or Chinese.
Inspections work offline on the mobile app and sync when connectivity returns.
Copilot-assisted inspection template creation exists but is preview — say so if you demo it.

When to use / skip

Use inspections for anything that is a checklist, a questionnaire, or a compliance form. Safety briefings, pre-work checks, pass/fail tests, customer satisfaction questions, statutory inspection sheets. The test I use: if the business would otherwise print it on paper and file it, it's an inspection. If someone would query it in a Power BI report with a WHERE clause on a specific value, think harder.

Use custom tables when the captured data drives something else in the system. Readings that trigger a follow-up work order, measurements that feed a billing calculation, condition scores that determine the next service date, anything that needs a relationship to another record, anything with a rollup or a business rule on it. The moment your requirement includes the word "then", inspections are the wrong container — you're going to end up writing a plugin that parses inspection responses, and that plugin will break the next time someone revises the template.

The volume test matters too. Ten questions on a boiler service is an inspection. A four-hundred-question statutory survey with scoring and sub-sections will make the technician's day miserable whichever technology you pick, and usually signals a process that needs breaking up rather than digitising as-is.

What I'd actually do: inspections for the bulk of it, custom columns on the work order or a related table for the handful of values that are reported on, calculated with, or acted upon. Yes, that means capturing a few things twice in the design conversation. It's still cheaper than either extreme.

Configuration decisions

Split the capture list into "reported on and acted upon" versus "recorded and reviewed". The first list becomes schema, the second becomes inspections.
Decide the attachment point: incident type (so it lands on every work order of that type), individual service task, or asset-based inspection outside a work order.
Decide the versioning discipline — who is allowed to revise a published inspection, and whether revisions are batched to a release cycle or done ad hoc. This is a governance decision, not a technical one.
Decide the ALM route for inspections. They travel as JSON, separately from your solution, which means someone owns moving them and someone owns keeping test and production in step.
Decide whether inspection responses feed Power BI directly or get flattened into reporting columns by a flow. If the answer is "directly", validate that the reporting team can actually work with the response structure before you commit.
Decide the language and PDF requirements early — the export limitations are real and there's no configuring round them.

Gotchas

Revising and republishing loses the previous version. If the client expects an auditable trail of "which version of the form was in force on this date", inspections alone won't give it to them without extra work.
Work orders created before a revision keep the old questions. That's right behaviour, and it makes period-over-period reporting messy when the question set changes.
Reporting on responses is materially harder than reporting on columns. Clients who saw a slick demo assume the data is on the work order. It isn't.
One rule per question's visibility limits how expressive branching gets. Complex conditional logic that would be trivial in a form gets awkward.
PDF export drops custom date and number formats. Clients with a required output format find this in UAT.
Building automation on top of parsed inspection responses couples your logic to a template that a non-developer can revise at will.

Consultant notes

Ask the client for their paper forms in discovery. They exist, someone has a folder of them, and they answer the whole question faster than any workshop.
Demo the designer to the business, not to IT. The point of inspections is that a service manager maintains them, and that only lands if they've seen themselves doing it.
Say clearly and early where inspection data lives and what reporting on it costs — the most common source of late-stage disappointment on these projects. If you demo Copilot-generated templates, label them preview.
Push back on migrating a four-hundred-question survey unchanged. Offer branching and a split across service tasks instead.
Before go-live, confirm someone owns inspection ALM between environments and that the process has been rehearsed at least once.

Worth revisiting if inspection versioning gains proper history, or if the response tables get a friendlier reporting surface.