What is conditional visibility?

Conditional visibility is branching logic on audit questions tied to a location attribute. If a store has a tap system, the line-cleaning question appears. If it does not, the question never shows and the store is not scored against it. A C-store Area Manager running mixed-format stores hears this from the field constantly. As one operator at Huck's put it, location-based logic "would come in handy for like the cold temps because not all of our stores have like a tap system."

Response routing is the next layer. It branches on the answer, not the location. The same question can fire different actions depending on how it gets answered. A pass does nothing. A fail reveals a follow-up question, requires a photo, opens a corrective task, and sends the alert to the assigned recipient. So the two ideas are distinct. Conditional visibility decides which questions appear. Response routing decides who gets alerted when an answer fails.

That is the difference between location-based and response-based conditional logic in one line. Location-based logic is tied to store format. Response-based logic is tied to the answer. Both run inside the same audit template.

Conditional visibility pairs with nullify scoring, the audit feature that makes hidden N/A items count for nothing. Hide the irrelevant question, and nullify scoring makes sure the missing item does not tank the score. The two features work together. A fuel-only store does not get marked down for missing food-service equipment, and a tap-system store is not penalized at non-tap units.

For the full definition and the format-variation patterns this Collection covers, start with the conditional visibility explained guide. For the C-store version specifically, the tap-system vs. fuel-only store breakdown walks through which questions show up where.

Worked example, conditional visibility in action

A 60-store C-store chain runs one fuel-and-forecourt audit, and the branching is response-driven, not just location-driven. If a store records a fuel-price mismatch, the audit reveals a root-cause follow-up and a required photo, then routes the alert to the fuel vendor and copies the DM. If a cooler reads out of range, it routes to the area maintenance tech instead. Stores with a tap system also surface a line-cleaning question whose failed answer escalates to the food-service lead. One template, but the answer decides who hears about the problem and how fast.

Break it into three response paths and the routing fork is clear:

1. Fuel-price mismatch (a pricing failure). The follow-up asks "What was posted versus what was in the POS?" and requires a photo of the pump display. The alert routes to the fuel vendor, a third party who is not a Xenia user, and copies the DM.
2. Cooler out of range (an equipment failure). The follow-up asks for the current reading and a photo of the thermostat. The corrective task goes to the area maintenance tech, not the vendor. Same form, different answer, different recipient.
3. Tap-system line check (a food-service failure, and a conditionally visible question). The line-cleaning question only appears at tap-system stores. That is conditional visibility. When the answer fails, it escalates to the food-service lead. This is the clearest illustration that the two ideas stack: the question is location-gated, and the answer is recipient-gated.

Here is the same logic as a routing table.

| Tier / Condition | Question group shown | Recipient when the answer fails |
|---|---|---|
| Any store, fuel-price mismatch recorded | Fuel pricing, forecourt signage | Fuel vendor, DM copied |
| Any store, cooler reads out of range | Cooler and equipment temp checks | Area maintenance tech |
| Tap-system stores only, line check fails | Tap-system line cleaning (hidden at non-tap stores) | Food-service lead |

This is where Xenia's follow-up questions and required image capture triggered by a failing answer earns its place. The fuel-price mismatch triggers a root-cause prompt plus a photo of the corrected price label, and the cooler issue triggers a description plus a photo of the equipment. The evidence is captured at the moment of failure, not reconstructed later. The platform stores that photo as compliance evidence. It does not interpret the photo's contents.

Why this matters. On a static audit, all three of these land in the same report as flagged items. The DM reads the report the next morning and starts making phone calls to figure out who owns each one. Response routing collapses that into three alerts that already found the right owner at the moment of the answer.

The fuel industry already runs this pattern on paper. The Envoy Air station fuel self-audit discrepancy and response procedure requires that items affecting service or safety be corrected immediately, with the action recorded, while non-critical findings get a written vendor response to the responsible station manager within a set window. Operators already route findings to vendors and managers by severity. They do it by hand today. Response routing makes the audit do it automatically.

How does conditional visibility differ from static audits?

A static audit shows every question at every store and treats every failure the same. A response-routed conditional audit shows only the questions that apply, then sends each failed answer to the specific person who owns it. The table below shows the gap.

| Dimension | Static audit | Response-routed conditional audit |
|---|---|---|
| Which questions appear | Every question at every store, irrelevant ones marked N/A by hand | Only the questions that apply to the store's format show |
| What a failed answer does | Records a flagged item in a report | Reveals a follow-up question, requires a photo, opens a corrective task |
| Who hears about a failure | Whoever reads the report later | The recipient the answer points to (vendor, tech, DM, food-service lead) |
| Speed to the right person | Next report cycle, plus phone calls to find the owner | At the moment of the answer |
| Evidence | Captured later, if at all | Photo captured at the moment of failure |
| Third-party vendor reach | Email or phone, outside the system | Alert reaches a non-user vendor via a QR work request that needs no login |

For the C-Store Area Manager, the bottom three rows are the ones that close the deal. The static audit makes you the switchboard. You read the report, you decide who owns each flagged item, and you chase the close. The response-routed audit does that work the moment the store answers.

Response routing is the trigger, not the closure. A failed answer feeds the corrective-action tracking workflow, which sets the assignee and deadline and escalates if the deadline passes. They are not the same feature. Routing decides who hears about the problem. The corrective-action workflow drives it to resolution.

Two named competitors are worth being honest about here. Zenput, now part of Crunchtime, is checklists-only. The alert can fire, but the work order and the team comms live in a separate tool, so the operator stacks Zenput plus a work-order system plus Slack. That is why Graham Enterprise moved off Zenput to Xenia, with conditional visibility plus the facilities workflow Zenput does not carry as the drivers. RizePoint has Action Plan Rules and Feedback Rules that generate a plan and send notifications based on a response, and it supports multi-level approval steps. The honest framing is not that RizePoint cannot route. It is that the conditional logic is a costlier add-on, the audit and the corrective-action closure are separate motions, and there is no native all-in-one comms and work-order layer to reach a third-party vendor with no login.

How to set up conditional visibility in Xenia

You set up a response-routed conditional audit in Xenia by building one template, gating the format-specific questions, and adding answer-based routing in the Logic Builder. Here are the steps.

1. Build one template for the whole fleet. Add every question the network might need, fuel price, cooler temp, tap-system line check, forecourt signage, in a single fuel-and-forecourt audit.
2. Set conditional visibility on the format-specific questions. Tie the tap-system line-cleaning question to the tap-system stores so it only appears where it applies. Pair it with nullify scoring so non-tap stores are not scored against it.
3. Add response logic to the questions that can fail. In the Logic Builder, set the condition (for example, fuel price mismatch equals Yes) and choose the actions: reveal a follow-up question, require a photo, and create a corrective task.
4. Assign the recipient per answer. Point the fuel-price failure at the fuel vendor and copy the DM. Point the cooler failure at the area maintenance tech. Point the tap-system failure at the food-service lead. The answer chooses the recipient.
5. Set the escalation tier. Define the chain: corrective task to the DM, escalate to Regional if it is not closed by the deadline, with a separate path for personal-injury incidents. Refuel runs this exact DM-to-Regional flow with a personal-injury tier.
6. Roll it out across the fleet. One template now routes correctly at every store regardless of format. If you already have a fuel-audit SOP as a PDF, the AI Template Agent converts it into a digital form with the conditional questions and required fields built in. It speeds the build. It does not invent the audit for you.

One clarification operators ask about: yes, a single failed answer can reveal the follow-up question and require the photo at once, in the same step. The follow-up question and the photo requirement fire together from one failing answer. The photo is stored as compliance evidence at the moment of failure. The platform does not auto-interpret what is in the photo.

Where do operators see results?

Operators see results as faster time-to-owner. The alert finds the right person at the moment of the answer instead of waiting for a report cycle, which means fewer phone calls and faster closure. The closest verified analog is Mezeh, which saw a 60% reduction in manager phone calls after frontline accountability moved into the system. That number is specific to Mezeh, not a fleet-wide average. But it shows the mechanism: when the form does the routing, the manager stops being the switchboard.

The pattern sticks at volume. H&S Energy runs a fuel-price form with more than 4,000 submissions, the exact form type where a price-mismatch answer should route straight to the vendor. The escalation depth is real, not theoretical. Refuel runs a documented DM-to-Regional escalation flow that escalates on personal injury with a fatality-tier path. That is the C-store approval chain the routing logic maps to, tier by tier. Huck's runs conditional checklists for tap-system versus non-tap stores, which proves the visibility half of the same pattern in the field.

Rollout speed holds at scale too. Power Market went live across 360 locations with bilingual checklists and QR deployment and reported 40% faster task resolution. That is the deployment reality for a multi-format fleet adopting routed audits.

There is a dashboard payoff that an Area Manager feels every morning. The 50-location group does not want a completion-percentage view. They want to see what is coming up as issues. Response routing feeds that view directly. Every failed answer that routed somewhere is also an open item the DM can see trending by region, so the dashboard surfaces where the next failure is forming instead of whether yesterday's tasks got done.

This is the operating model convenience-store operators run on Xenia: one audit template across mixed formats, answers that route to the right owner, and a dashboard that shows the issues, not just the percentage. For the seasonal version of the same logic, the seasonal conditions audit guide covers how the questions and routing shift across the year, and the conditional audits overview ties the whole approach together.