What is conditional visibility?

Conditional visibility is branching logic that shows or hides audit questions based on an attribute stored on the location record. When a store's attribute matches a rule, the matching question group appears. When it does not, that group stays hidden. It is deterministic location-attribute branching, not AI, and not a general form builder.

In the classic case the attribute is a physical trait: patio or no patio, tap system or fuel-only. A risk-based audit uses a different attribute, the unit's prior audit performance. The last one or two audit scores, plus an open-critical-corrective-action flag, sit on the record. Same mechanism, different dimension. This is the same idea behind running one audit template across 100 franchises where units with drive-thrus see drive-thru questions and units with patios see patio questions. Here the branching key is track record instead of layout. Conditional visibility branching for multi-format audits is what turns one template into a short walk or a full audit depending on the unit in front of you.

Conditional visibility pairs with nullify scoring. Nullify scoring keeps hidden questions out of the score denominator, so a strong unit's short walk is scored only on the questions it actually answered. One feature hides the irrelevant questions. The other makes sure the hidden ones do not tank the score.

Draw the distinction clearly, because it is the whole reason this pattern exists. This is not the same as setting a fixed audit frequency by vertical. Frequency-by-vertical decides how often you audit a whole class of stores. A performance-based audit frequency applied at the question level decides how deep the audit goes for one specific unit based on that unit's own record. Risk-based branching changes audit depth inside a single template, not cadence across a vertical. It is one piece of a broader conditional audit program that adapts the walk to the unit.

Worked example, conditional visibility in action

Here is the pattern in one concrete scenario. A 200-unit restaurant chain runs one operations audit that carries 46 questions in total. Each unit's prior performance on the record decides how much of it renders. The question groups fall into three bands.

The always-on core (food safety, line check, active promo) is verified on every single walk, no matter how strong the unit. Mid-tier additions (foundation drills, POS config) render for units that are solid but not spotless. Full-audit additions (training verification, remediation follow-up, open-critical-corrective-action review) render only for the units that need the deepest look.

The prior-performance attribute, not the auditor's calendar, decides the question set. Three risk tiers sort every unit automatically.

| Tier / Condition | Audit type | Question groups shown | Question groups hidden | Question count |
|---|---|---|---|---|
| Scored 90% or higher on the last two walks | Exception audit | Food safety, line check, active promo | Foundation drills, POS config, training verification, remediation follow-up | 18 |
| Scored between 75% and 90% last walk | Mid-tier walk | Food safety, line check, active promo, foundation drills, POS config | Training verification, remediation follow-up | 32 |
| Scored below 75%, or has an open critical corrective action | Full audit | All groups, including training verification, remediation follow-up, and open-critical-corrective-action review | None | 46 |

Now the nullify-scoring payoff, because this is what makes one template work instead of two. The strong unit that only answers 18 questions is not scored as if it skipped the other 28. Nullify scoring removes the hidden questions from the denominator.

The exception walk is scored on 18 of 18, so a clean walk reaches a true 100%. Without nullify scoring, an exception audit would look like a unit that abandoned two-thirds of the checklist.

A location without a patio does not get dinged on patio cleanliness, and a strong unit does not get dinged on the drills it earned the right to skip. That is the pairing that lets a short exception audit and a full audit come out of the same form.

Risk tier is only one dimension you can branch on. You can also branch on who is running the walk with auditor-role conditional audits or on who owns the unit with franchise-tier conditional audits. The remaining questions can still carry different weights, so weighted audit scoring with critical-item thresholds keeps a temp failure worth more than a smudged menu board even on the short walk.

How does conditional visibility differ from static audits?

A static audit shows every unit the same 46 questions and scores a strong store against groups it did not need reviewed. A conditional risk-based audit renders only the question groups the unit's track record warrants and scores only those. The difference shows up in auditor hours, score signal, and how many templates you have to maintain.

| Approach | Behavior at hidden or N/A items | Score impact | Templates required |
|---|---|---|---|
| Static audit (one template for all) | Every unit sees all 46 questions regardless of performance | Strong units burn auditor time on low-risk groups, scores compress and stop signaling risk | One template, but no depth control |
| Duplicate templates (a short form and a long form) | Auditor manually picks which form to run per unit | Two records to reconcile, version drift when the core changes | Two or more templates to maintain |
| Conditional risk-based audit (Xenia) | Hidden groups do not render for strong units, nullify scoring removes them from the denominator | Strong unit scores 100% on the 18 it answered, at-risk unit is scored on all 46 | One template, depth set by the prior-performance value |

For a Franchise Compliance Officer, the governance win is that audit resource allocation is now defensible. Audit hours concentrate on the units carrying open corrective actions and sub-75% history, not on stores that already proved they are clean.

The board report shows the distribution of units across risk tiers, not a flat "we audited everyone once" number. That is a far stronger answer when someone asks where the audit budget went.

This is also where the incumbents fall short. Zenput's documented weakness is the absence of question-level branching, so a Zenput shop runs duplicate templates to get short-versus-full behavior.

That is exactly the two-record reconciliation problem in the middle row above. If you are weighing exception audit software against a checklist-only tool, the honest breakdown of Zenput alternatives covers how a single conditional template replaces the duplicate-form workaround.

How to set up conditional visibility in Xenia

You can build a risk-based exception audit from one template in six steps. Keep the prior-performance value deterministic. It is a known number an operator or a regional roll-up sets, never a prediction.

1. Add a prior-performance value to each location record. Store the unit's last audit score, or a risk tier like exception, mid, or full, plus an open-critical-corrective-action flag. An operator or a regional roll-up sets this value. It is a known number, not a guess.
2. Build one audit template with grouped questions. Group the 46 questions into the core, mid-tier, and full-audit bands. Food safety, line check, and active promo are the always-on core.
3. Set conditional visibility rules on each group. Tie the mid-tier and full-audit groups to the prior-performance value, so a 90%-plus unit renders only the core and a sub-75% unit renders everything.
4. Turn on nullify scoring for the conditional groups. This keeps hidden questions out of the score denominator, so a strong unit's exception walk can reach a true 100%.
5. Set the always-on core to render for every tier. Food safety, line check, and active promo verify on every walk regardless of tier, so no unit ever skips the non-negotiables.
6. Route corrective actions and re-tier after each walk. When a walk closes, update the prior-performance value from the new score so the next audit renders at the right depth. A unit that drops below 75% or opens a critical corrective action moves to the full audit automatically on its next cycle.

Where do operators see results?

Operators see the payoff in two places: auditor hours land where the risk actually sits, and the corrective-action loop decides who earns the short walk. Dave's Hot Chicken migrated from RizePoint across 321 locations and rebuilt its program around weighted scoring, Bluetooth thermometer logging, and corrective-action workflows with deadlines and escalation.

The tie-in for risk-based auditing is direct. An open critical corrective action is a deterministic flag that pushes a unit into the full-audit tier. When a corrective task is still open past its deadline, that unit does not earn the short exception walk on its next cycle.

In Xenia, an out-of-range line check triggers a follow-up question, requires a photo of the fix, assigns a task to the kitchen manager with a deadline, and escalates to the DM if it is not closed. RizePoint's conditional logic is a paid add-on, and its N/A handling can penalize the score, so the exception-audit pattern is hard to run there.

Ace Retail Group consolidated its audit program after leaving Bindy, running comms and multi-banner audits in one place. For a Franchise Compliance Officer with a multi-banner estate, risk-tiering is how you govern audit depth across banners from one template instead of buying per-seat licenses and juggling separate short and long forms.

Graham Enterprise left Zenput specifically for conditional visibility, which is the proof point that question-level branching is the switching driver, not a nice-to-have. On execution speed, Power Market went live across 360 convenience-store locations and reports 40% faster task resolution, the kind of loop that closes corrective actions before they force a unit back into the full audit.

Risk-based auditing is not a fringe idea. The Institute of Internal Auditors now requires it: under the IIA's risk-based internal audit plan guidance, the audit plan must be built from a documented, annually refreshed risk assessment.

What no competitor shows is how that best-practice theory renders in software, one template that changes question depth per unit by prior performance. For teams standardizing this across a multi-unit restaurant operations platform, that single-template execution is the whole point.