Conditional logic and branching in inspections

What it does

Branching rules let an inspection change shape as the technician answers it — showing a page, revealing a question, making something mandatory, or jumping ahead. Rules are built on the Logic tab of a draft inspection template as condition-plus-action pairs, and they run client-side in the mobile app, so they work offline.

Key facts

Four rule actions are available: Make Page Visible, Show the Question, Change to Required, and Skip to Question.
Rules are authored on the Logic tab of a draft template via Create rule. You can only edit logic on a draft — a published template is read-only until you select Revise.
A rule is a condition (a question and the response it must have) plus an action; multiple conditions can be combined on a single rule.
Logic is evaluated on the device against answers already given, which is what makes it work with no connectivity.
Hidden questions are hidden, not deleted. If a question was answered and then a later answer hides it, be careful about what you assume is in the response payload.
Change to Required interacts with the mobile app's completion validation: the technician cannot mark the task complete until visible required questions are answered.
Translations are a separate tab on a draft template, and only work for languages already enabled on the environment in Power Platform admin.
Copy on the Inspection Templates list duplicates a template, which is the practical way to branch a template family rather than trying to make one template cover every variant with logic.
Logic lives in the same JSON as the questions on the msdyn_inspectiondefinition version record, so it versions and publishes with the questions, never separately.

When to use / skip

Use branching when a genuinely different set of questions applies depending on an early answer — equipment type, pass versus fail, whether the customer was on site. The classic and best use is a fault-detail page that only appears when the technician answers "Fail", which keeps the happy path to three taps and still captures a proper report when something is wrong.

Skip it when you're using logic to bolt several unrelated inspections into one template. If the branches share almost no questions, you want separate templates on separate service task types — they're easier to version, easier to report on, and the dispatcher can see from the work order which one is actually being done. Also skip complex nested logic where the client's real requirement is calculation or validation; the rule engine here shows, hides and requires, it does not compute, compare numbers against tolerances, or validate against other Dataverse records.

Configuration decisions

Which single question is the branch driver, and whether it belongs on its own first page so the form reshapes before the technician scrolls.
Whether to branch inside one template or split into multiple templates on separate service task types — decide by how much the branches share.
Whether conditionally shown questions should also be conditionally required, and what the technician is expected to do when a required question appears late in the form.
Which languages the workforce actually needs, since translations must be set up per draft version and re-checked after every revise.
How reporting handles skipped questions — an unanswered question because it was hidden and an unanswered question because the technician skipped it look identical downstream unless you design for it.
Whether any "logic" the client is asking for is really automation, which belongs in a Power Automate flow on the parsed response rather than in the template.

Gotchas

Logic can only be added or changed on a draft. If you need to fix a rule on a live template you must Revise, edit and republish, and the previous version is gone.
Skip to Question is easy to get wrong when combined with page visibility rules — test the full matrix in Preview, because the mobile app is where users find your dead ends.
A hidden required question does not block completion, but if a later answer makes it visible again it does. Technicians report this as the app "randomly refusing to save".
Deleting a question that a rule depends on leaves the rule pointing at nothing. The designer does not always make this obvious; re-open the Logic tab after any question deletion.
Translations are attached to the draft version. Revise a published template and you'll want to confirm the translated strings survived before you publish over the live version.
Branching does not reduce the size of the response JSON in any useful way. Long templates stay long to parse regardless of how few questions the technician saw.

Consultant notes

Demo branching with a pass/fail asset check. It is the fastest way to show a client why an inspection beats their existing PDF, and it takes about ninety seconds.
Insist on a walkthrough of every branch on an actual phone before go-live. Preview in the designer is honest about logic but not about thumb reach and scroll length.
When a client asks for arithmetic — "flag it if the reading is outside tolerance" — tell them plainly that the template can't do it, and scope a flow on the parsed response instead. Getting this straight early saves a fight in UAT.
Keep rule counts modest per template. Nobody has published a hard limit, but templates with dozens of interacting rules become unmaintainable long before they become slow.

Worth another look if Microsoft extends the rule actions beyond show, hide, require and skip.