What it does

An inspection template is a container; the questions live on a child Inspection Template Version record. Publishing marks a version live, revising creates a new draft, and republishing replaces what was live. Work order service tasks keep a lookup to the exact version they were created against, so old tasks keep old questions.

Key facts

• The version table is msdyn_inspectiondefinition (Inspection Template Version), a child of msdyn_inspection via msdyn_ParentInspectionId, with cascade delete on.
• msdyn_state on the version is the lifecycle field: 0 is Draft, 1 is Published. That is separate from the ordinary statecode Active/Inactive.
• Questions and logic are stored in msdyn_JsonContent (memo, up to 1,048,576 characters). msdyn_Version is a string, msdyn_EffectiveDate records when the version takes effect, and msdyn_IsDefault marks the version the template currently points at.
• msdyn_IsRequiredToAnswer flags whether the version contains mandatory questions; msdyn_IsProcessed tracks whether the deserialisation flow has handled it.
• A published template is read-only in the designer. Select Revise to get an editable draft.
• Publishing a revision replaces the previous published version. Earlier versions are not retained as a browsable history.
• msdyn_workorderservicetask holds msdyn_inspectiondefinitionid, pointing at the version stamped when the task was created. Existing tasks do not pick up a republished template.
• Template Name is fixed after the first publish. Description and questions are not.
• Copy on the template list creates a new template from an existing one, which is how you fork a variant rather than versioning one template into two shapes.
• Export to JSON and import is the supported route between environments. Re-importing an unchanged export into the environment it came from breaks the out-of-the-box deserialisation flows.

When to use / skip

Versioning isn't optional — it's simply how the feature works — so the real question is how you govern it. On any client with regulated or safety-critical inspections, treat a republish as a controlled change: draft in a non-production environment, review, export, import, publish. On a low-risk internal checklist, letting the operations lead revise and republish directly in production is fine and is one of the genuine selling points of the module.

What you should skip is any attempt to build a version history the product doesn't give you. People try to solve "we need to prove which questions were asked in March" with copies of templates named v1, v2, v3, and end up with an unusable list and reporting that splits across four question sets. If the client has a genuine evidentiary requirement, the answer is the exported response PDF and the parsed response rows, not template archaeology.

Configuration decisions

• Where templates are authored: production directly, or built in dev and moved by JSON export/import. This is the main governance decision and it should be made once for all templates.
• Whether inspection templates travel in solutions as part of your ALM pipeline or are handled as data alongside it.
• Who holds Field Service - Administrator, since that is the role that can publish and associate templates to service task types.
• Whether "publish and generate a new service task type" is allowed, or whether task types are created deliberately to keep the list tidy.
• Naming and numbering convention, given the name is immutable — decide whether version numbers go in the name at all (usually they should not, since the version record carries one).
• What the change process is for a live template: who approves, how it's communicated to technicians, and whether in-flight work orders need reissuing.

Gotchas

• Republishing does not update work order service tasks that already exist. Bookings scheduled weeks out will still show the old form when the technician arrives. If a question change is mandatory from a date, you have to deal with the existing tasks yourself.
• There is no rollback. Publish a broken revision over a good one and the good one is gone — your only copy is whatever JSON you exported beforehand.
• The immutable Name bites hardest on templates created during a proof of concept and then promoted. Rename before the first publish or live with it.
• Cascade delete from template to version means deleting a template takes its versions with it, and anything still referencing them is left in an unhappy state. Deactivate rather than delete.
• Changing question text in a revision quietly forks your reporting, because parsed responses key on the question. A version bump that reads as cosmetic can break a Power BI report.
• Logic and translations exist only on a draft version. After Revise, check both before publishing — people frequently publish a revision and discover the translations they set up last quarter are not where they expected.

Consultant notes

• Export every published template to JSON and store it in source control alongside the solution. It takes minutes and it is the only rollback you have.
• Make the "existing tasks keep the old version" behaviour an explicit line in the design document and get it signed off. It is the single most common surprise on inspection projects and it is much easier discussed in design than in a compliance review.
• If the client wants team leaders maintaining forms, walk them through Revise and Publish in a sandbox and let them break something. It's a two-hour session that prevents a production incident.
• Before go-live, confirm which template version each active service task type is pointing at, and that no draft has been left unpublished with everyone assuming it's live.

---

Worth another look if Microsoft adds retained version history or a rollback to a previous published version.