What it does

A completed inspection is saved as a blob of JSON on an Inspection Response record. To report on individual answers you turn on inspection analytics, which runs out-of-the-box Power Automate flows that shred that JSON into the Customer Voice question and response tables. Until you switch that on, you have answers but nothing to query.

Key facts

• Raw answers land in msdyn_inspectionresponse as JSON. Images and files captured during the inspection land in msdyn_inspectionattachment as annotations.
• Parsed data goes to three Customer Voice tables: msfp_question (one row per inspection question), msfp_surveyresponse (one row per completed inspection) and msfp_questionresponse (one row per answer to per question). These are the tables you build reports against.
• Analytics is off until you set it. Field Service Settings > Inspection tab > Analytics enabled = Yes, then pick an Analytics frequency.
• Analytics frequency options are Immediately, Daily, or Custom with an interval of 1 to 365 days.
• With Immediately, a response is parsed on completion and is not re-parsed if the technician later changes an answer. With Daily or Custom, the latest completion before the flow's start time is what gets stored.
• Three out-of-the-box flows do the work: Deserialization of Inspection Definition Flow (publishes questions into msfp_question), Deserialization of Inspection Response Flow (Immediate), and Deserialization of Inspection Response – Recurrent Flow (Daily/Custom).
• Questions only appear in msfp_question once a template has been published, so the question catalogue is populated by the definition flow, not by authoring.
• The out-of-the-box flows can't be edited in place. If you need different behaviour, copy them and disable the originals.
• Reporting is done with Power BI over the Dataverse tables, or with Power Automate reading the raw JSON when you want to trigger something — a follow-up work order off a failed answer, for example.

When to use / skip

Turn analytics on for any client who has said the word "reporting" in relation to inspections, which is all of them. Without it the answers are only readable one work order at a time, and a year later somebody will ask how many boilers failed the flue test and the answer will be an expensive JSON-parsing exercise.

Leave it off only where inspections are purely an evidence trail — a signed-off checklist that exists for audit and is read individually if ever. The flows cost flow runs and add rows to three tables per inspection, and on high volumes that is not nothing.

For genuinely analytical requirements at scale, plan to move parsed responses out to a lake or a warehouse via Synapse Link rather than reporting live over Dataverse. The Customer Voice tables are workable but they're a long, thin key-value shape and Power BI models over them get slow before the row counts look alarming.

Configuration decisions

• Whether analytics is on at all, and at what frequency. Immediately is simplest and most common; Daily suits high-volume operations that don't need same-day numbers.
• Whether technicians are ever expected to amend a completed inspection, because that decision makes Immediately the wrong choice.
• Whether reporting stays in Dataverse and Power BI or goes out via Synapse Link, decided by expected annual inspection volume.
• Whether any answer needs to trigger automation, and whether that automation reads the raw JSON on msdyn_inspectionresponse or waits for the parsed rows.
• Retention: how long parsed responses and attachments are kept, and who owns deleting them.
• Whether copies of the out-of-the-box flows are needed, and if so, who maintains them through Field Service updates.

Gotchas

• Forgetting to switch on analytics is the classic. Everything looks fine for months, then someone asks for a report and there is no parsed history to build it from — turning it on now does not backfill.
• With Immediately, subsequent edits by the technician do not update the parsed rows. The report and the work order can disagree, and the work order is right.
• Question text is what identifies a question in the parsed data. Reword a question in a revision and your report starts splitting one measure into two.
• The deserialisation flows are ordinary Power Automate flows and they fail like ordinary flows — on throttling, on a malformed template, on a connection whose owner has left. Nothing in the Field Service UI tells you they've stopped; you have to look in Power Automate.
• Re-importing an unchanged exported template JSON breaks the out-of-the-box flows. Change something, or don't re-import.
• Attachments are annotations, so they count against storage in the way notes do and they are not neatly joined to the parsed answer rows.
• The flows run in the environment's context and consume flow runs. On a client doing thousands of inspections a month this shows up in Power Platform capacity conversations.

Consultant notes

• Turn analytics on during the build, not at go-live. It costs nothing in a dev environment and it means UAT data is already parsed when someone asks for a sample report.
• Add the deserialisation flows to whatever the client uses for flow monitoring on day one. A silently stopped flow is the most likely cause of "the inspection dashboard stopped updating".
• Warn the client that question wording is effectively a reporting key. Agree that question text changes go through the same review as any other reporting change.
• Build one real Power BI page over msfp_questionresponse during the project and show it to the client. It's the fastest way to surface the fact that their planned 40-question form produces an unreadable report.
• Check flow run volumes against licensing before go-live if inspection volumes are high.

---

Worth another look if Microsoft moves inspection analytics off the Customer Voice tables or off out-of-the-box Power Automate flows.