Overview
Mobaro lets you configure Checklist questions to be visible only to the assignee, only to the reviewer, or to both. The mechanism: state-based logic that reads the Checklist's current state (pre-approved, awaiting validation, approved, disapproved) and shows or hides each question accordingly. The pattern enables in-app validation flows where an operator captures answers, then a reviewer adds their own answers and signs off — all on the same Checklist. Used well, this powers long-distance assessment, training feedback, and four-eyes principle workflows without needing separate Checklists.
The mental model: A Checklist with state-based logic isn't really one Checklist — it's two phases of the same Checklist, with the state determining which questions you see. Phase 1 (assignee): Checklist is "not equal to awaiting validation," so the assignee-only questions show. Phase 2 (reviewer): Checklist is "equal to awaiting validation," so the reviewer-only questions show.
Required setup: To use state-based logic, the Schedule must require validation, and at least one User must hold a Reviewer Role with validation authorization. See validation prerequisites in the related Checklists documentation, and how Checklist logic works for the underlying logic engine.
The four Checklist states
A Checklist's state changes as the Result moves through its lifecycle. The four possible states are:
Pre-approved
A Checklist that doesn't require validation, and is completed within its nominal timespan. Pre-approved Results don't enter a review queue — they're done when the assignee submits them.
Awaiting validation
Requires explicit validation by an authorized User. Either the Schedule requires validation by default, or one or more compliance rules were triggered (e.g., the Result was completed outside its deviation window). The Result sits in the reviewer's queue until acted on.
Approved
Has been explicitly approved by a reviewer. Final state for accepted Results.
Disapproved
Has been explicitly disapproved by a reviewer. Final state for rejected Results — the work is on the record but flagged.
State-based logic typically pivots on awaiting validation — the state in which the reviewer is interacting with the Checklist. Questions configured "Checklist is equal to Awaiting validation" appear during the review phase only. Questions configured "Checklist is not equal to Awaiting validation" appear in every other state — i.e., to the assignee and on the final report.
Adding state-based logic to a Checklist
The setup happens during Checklist configuration on the web Backend.
1. Open the Checklist
Go to the Checklists tab and open an existing Checklist or create a new one.
2. Pick the question to configure
Click the question (or section) you want to scope to assignee or reviewer only. Scroll down to the Logic section.
3. Add logic based on Checklist state
Click Add logic and choose Based on a Checklist state.
4. Configure the visibility rule
Two patterns cover most use cases:
Visible to assignee only: Checklist is Not equal to Awaiting validation.
Visible to reviewer only: Checklist is Equal to Awaiting validation.
5. Save
Save the question and the Checklist. The logic takes effect for new Results captured against this Checklist version.
Note: Questions without state-based logic are visible to both assignee and reviewer. Adding state-based logic is opt-in per question — you don't need to scope every question, only the ones that should be phase-restricted.
Reviewing a Result on the mobile app
Once a Result is awaiting validation, an authorized reviewer reviews it from the mobile app:
1. Open the Checklists tile
Go to the Checklists tile in the mobile app.
2. Find the validation queue
Look for the validation icon in the top-right corner. The badge shows the number of Results awaiting validation. If the icon isn't there, either nothing is queued or the User isn't authorized for validation.
3. Open a Result and review
Pick a Result from the queue. The Checklist runs as normal, but now the reviewer-only questions are visible. The reviewer can also see, edit, and comment on the assignee's answers.
4. Approve or disapprove
At the end, press Done, then choose Approve or Disapprove. Comments and attachments can be added with the decision.
Note: The final Result report shows both the assignee's answers and the reviewer's answers, clearly separated. This makes the report a complete record of both phases — no information from either phase is lost.
Worked examples
Example 1: Long-distance assessment
Scenario: A regional safety supervisor reviews safety Checklists from multiple parks without traveling to each location. Operators capture the on-site readings; the supervisor adds reviewer notes and grades remotely.
Setup: Safety inspection Checklist with all measurement questions visible to the assignee (state ≠ awaiting validation). Reviewer-only questions added for the supervisor's grading and overall comments (state = awaiting validation). Schedule requires validation.
Result: The supervisor reviews each Result from the headquarters office. The assignee's measurements are visible; the reviewer's grading questions appear only during validation. Both surface on the final report. The supervisor scales across multiple parks without on-site travel.
Example 2: Training feedback for new operators
Scenario: A new technician learning preventive maintenance Checklists. A trainer reviews each Checklist after the technician completes it, providing feedback and corrections.
Setup: Standard PM Checklist with reviewer-only feedback questions added (state = awaiting validation). Trainer holds a reviewer Role.
Result: Technician runs the Checklist normally. Trainer reviews on mobile, scoring the technician's performance and adding written feedback in the reviewer questions. The final report shows both the work the technician did and the trainer's assessment — useful for performance reviews and training documentation.
Example 3: Four-eyes principle for high-risk checks
Scenario: A safety-critical lap-bar restraint check requires a second qualified person to verify the assignee's work before the ride opens.
Setup: Restraint Checklist where the assignee captures the actual measurements (state ≠ awaiting validation). Reviewer-only questions for the supervisor's verification and signature (state = awaiting validation).
Result: Two qualified individuals see and sign off on the same record. The four-eyes principle is satisfied without the cost of running the same Checklist twice. See Designing Checklists for the four-eyes principle for deeper patterns.
Anti-patterns to avoid
Watch out for these patterns, which produce confused Checklists or broken validation flows:
Scoping every question to one phase or the other — if no questions are visible to both, the Checklist becomes unreadable. Most operational context (location, timestamps, common findings) should stay visible to everyone.
Forgetting to require validation on the Schedule — state-based logic only does anything if the Result enters the awaiting-validation state. A Schedule that doesn't require validation produces pre-approved Results, and the reviewer-only questions never appear.
Reviewing without reviewer Role permission — without the right Role, the validation queue badge doesn't appear on mobile. Confirm Role configuration before rolling out.
Confusing "Approve" the Result with "Approve missing" — these are different actions. Approve the Result is the final-state validation action on a completed Checklist. Approve missing is for missed-Result handling on the web Backend. See Approving or rescheduling missed Results.
Adding too many reviewer-only questions — review fatigue is real. Reviewer questions should be high-leverage: scoring, sign-off, exception flags. If the reviewer phase has more questions than the assignee phase, the Checklist is probably mis-designed.
See also
Designing Checklists for the four-eyes principle — for patterns specifically around two-person verification and sign-off.
How Checklist logic works — for the underlying logic engine.
Validation prerequisites — for the Schedule and Role configuration that enables validation flows.
The Compliance page in Result reports — for how the validation flow is documented in the final Result PDF.
Frequently asked questions
Q: Can a question be visible only in the Approved state?
A: Yes — state-based logic supports any state value, not just Awaiting validation. Configure "Checklist is equal to Approved" for post-approval-only visibility. This is rare in practice; most patterns pivot on Awaiting validation.
Q: Does the reviewer see the assignee's answers?
A: Yes. The reviewer can see, edit, and comment on the assignee's answers, plus answer their own reviewer-only questions. Edits are tracked in the audit trail.
Q: What happens if a Result is disapproved? Does it need to be redone?
A: Disapproval is a final state — the Result remains on the record marked disapproved. If the work needs to be redone, generate a new Slot (Ad Hoc, or wait for the next scheduled occurrence). Disapproval doesn't auto-create a new Slot.
Q: Can I require a reviewer signature on the validation phase?
A: Yes — add a signature question scoped to the reviewer phase (state = awaiting validation). The signature is captured during validation and appears on the final Result report.
Q: Does validation work in offline mode on mobile?
A: The reviewer can run the validation flow offline, and it syncs when the device next connects. As with any offline action, save and sync as soon as connectivity returns to avoid stale state if the Result is also being edited from elsewhere.