What is conditional visibility?

Conditional visibility is branching logic on audit questions tied to a location's format. It shows a question at a store only when that store's setup actually calls for it. A fuel-only site sees forecourt and merchandising questions. A store with a fountain and coffee bar sees those plus food-service and tap-line sanitation questions. The phrasing operators use is simple: if a store has a tap system, the temp and line-cleaning questions for it appear. If it does not, they do not.

Two things matter here. First, conditional visibility is deterministic. It branches off the store format on the location record, not off any guesswork. It is not AI, and it is not a general no-code form builder for arbitrary business processes. It is built for ops audits. Second, it pairs with nullify scoring but is a separate feature. Conditional visibility hides irrelevant questions. Nullify scoring makes sure the hidden questions do not count against the score. Hide versus do-not-count. They work together, but they are not the same thing.

For C-store operators, that pairing is the whole game. One convenience store audit template handles stores with tap systems, food service, fuel-only, or full-service formats. The irrelevant questions hide automatically per location group. You can read the full breakdown of how the two features lock together in the nullify scoring and conditional visibility pairing guide, and the wider conditional audits overview sets the category context. This is the same logic that drives patio versus no-patio restaurant audits. The vertical changes. The mechanism does not.

Worked example, conditional visibility in action

Here is the pattern in plain numbers. A 200-store C-store chain runs three forecourt formats: fuel-only, fuel plus food service, and full-service stores with a tap system. The audit template carries 48 questions overall. Conditional visibility decides which subset each store actually sees.

| Store format | Questions shown | What drives it |
|---|---|---|
| Fuel-only | 26 forecourt and merchandising questions | Base set every store sees |
| Fuel plus food service | 38 questions (26 base plus 12 food-service) | Food-service attribute on the location record |
| Full-service with tap system | All 48 (38 plus 10 tap-line sanitation and line-cleaning) | Tap-system attribute adds the final 10 |

The rule reads in plain English. If the store format on the location record is tap-system, show the 10 tap-line sanitation questions. If it is fuel-only, hide them and remove them from the score. A fuel-only store is graded out of 26, not 48. It is never marked down for the 12 food-service or 10 tap-system questions it should never have seen. Every store can score 100% because nullify scoring strips the hidden questions out of the denominator.

Why does a tap-system store carry 10 extra questions a fuel-only store never sees? Because dispensed beverages are food, and the equipment that pours them needs real cleaning. Industry testing summarized by FSR Magazine cites NSF International findings that soda fountains rank among the germiest spots in quick-service settings, with coliform bacteria found in close to half of machines tested. Standard practice, per FSR and Coca-Cola's fountain dispenser cleaning guidance, is daily cleaning of nozzles, diffusers, drip trays, and valves, plus a deeper weekly line clean. The FDA Food Code treats dispensed beverages and ice as food, so this equipment falls under food-contact-surface and cleaning-frequency rules.

Those norms are exactly what the 10 tap-system questions audit: nozzle cleaning logged, line-cleaning date current, drip-tray sanitation, dispensed-beverage temperature. None of it applies to a fuel-only store. That is the core of the conditional-visibility argument. The audit only asks each store what its format actually requires.

How does conditional visibility differ from static audits?

A static audit shows every store the same questions and scores them all out of the same total, so format variation creates false negatives. A conditional audit shows each store only its relevant questions and scores it only on those. That single difference decides whether your above-store view tells the truth.

|  | Static audit (one template, one question set) | Conditional audit (Xenia) |
|---|---|---|
| Questions per store | Same for every format | Branches by store format attribute |
| Fuel-only store score | Penalized for missing food-service and tap items | Scored only on its 26 questions |
| Template management | Duplicate templates per format (three templates, triple the upkeep) | One template, 100-plus format variations |
| N/A handling | Manual N/A entry, often still counts against the score | Nullify scoring removes hidden items from the denominator |
| Roll-up reporting | Scores not comparable across formats | Comparable, each store graded on its own scope |

Without conditional logic, the area manager has two bad options. Build and maintain three separate templates, or run one bloated template and watch fuel-only stores show artificially low scores because the system counted food-service questions they could never answer. Both options corrupt the roll-up. The DM walks then chase phantom gaps instead of real ones.

Zenput earned its reputation as a strong digital checklist and form tool, and it supports basic branching. But its architecture is checklists-and-forms-first, not purpose-built question-level conditional visibility, and its form-capped pricing punishes operators for adding templates. RizePoint sells conditional logic as a paid add-on. Bindy's audit logic is static. That gap is why Graham Enterprise migrated off Zenput to Xenia in the C-store vertical, with conditional visibility and the facilities workflow as the named drivers. You can compare the full feature set in the Zenput alternatives breakdown and the side-by-side Zenput comparison.

How to set up conditional visibility in Xenia

Setting up format-aware audits in Xenia takes six steps and one master template. The goal is one template that branches by store format, scored fairly with weighted audit scoring and critical-item thresholds layered on top.

1. Tag each location with its format. On the location record, set the store format attribute: fuel-only, fuel plus food service, or full-service tap-system. This tag is the trigger for every branching rule.
2. Build one master audit template. Include all 48 questions across all formats. Do not duplicate templates per format. One template is the entire point.
3. Set conditional visibility on the format-specific questions. The 12 food-service questions appear only when the format is food-service or tap-system. The 10 tap-line questions appear only when the format is tap-system.
4. Turn on nullify scoring for the conditional questions. Hidden questions drop out of the denominator, so every store is scored only on what it actually sees.
5. Add follow-up questions and required photo capture on the critical items. A cooler temp out of range or a fountain nozzle past its cleaning window triggers a description field plus a required photo, which auto-creates a corrective task tied to a deadline.
6. Roll out and confirm the branching. Publish to all stores. A fuel-only store opens the audit and sees 26 questions. A tap-system store sees 48. Confirm in the above-store dashboard that scores are comparable across formats.

One shortcut on rollout: Xenia's AI Template Agent lets you upload an existing SOP PDF, for example your tap-line cleaning SOP, and get a digital form back with the structure already built. That cuts setup from weeks to days. It transforms documents you already have. It does not write audits from a vague brief.

Where do operators see results?

Operators see results in three places: fewer false negatives, one template instead of three, and an above-store view that finally compares apples to apples. The dashboard leads with an issues view, not a completion percentage. As one C-store ops note put it, a 50-location group wants to see what is coming up as issues, not a vanity completion number.

C-store operators are already running this pattern in production:

• Huck's uses conditional checklists specifically for tap-system stores versus non-tap stores, including the cold-temp logs. It is the canonical conditional-visibility use case in the C-store world. The operator framing came straight from their team: not all stores have a tap system, so the temp questions for it should only show where the equipment exists.
• Refuel runs 200-plus C-stores, including rural fuel stops with intermittent connectivity. They use Xenia for offline-capable audits, work orders, and frontline ops, and keep Service Channel alongside it for asset depth. It is a complementary buy, not a rip-and-replace.
• Power Market (the H&S Energy banner) deployed Xenia across 360 locations with bilingual checklists and QR-code rollout, running a fuel-price form with 4,000-plus submissions and continuous Bluetooth and LoRaWAN sensor coverage. The result was 40% faster task resolution. The full story is in the Power Market customer case study.
• Graham Enterprise migrated from Zenput to Xenia in the C-store vertical, with conditional visibility and the facilities workflow as the named drivers.

The operational payoff is concrete. Fuel-only stores stop showing artificially low scores, so the area manager's store walks focus on real gaps. There is one multi-location audit software template to maintain instead of three, which matters a lot at 200 stores. And the format-aware logic carries across to adjacent ops work, from convenience store temperature monitoring to the daily convenience store checklist and walk-in cooler temperature standards. The same conditional logic that splits a tap system audit from a fuel-only one also drives franchise-tier conditional audits and seasonal-condition audits across the rest of the portfolio.