Overview
The four-eyes principle means two qualified people verify high-risk work before it's accepted. Mobaro has no single four-eyes switch; you build it from three features. State-based logic splits one Checklist into an assignee phase and a reviewer phase. The Schedule's validation requirement makes the reviewer phase happen. A reviewer-only Signature Question records who signed off.
The result is one Result that holds both people's answers, with a full audit trail. This article covers when the pattern is worth the overhead, how to design the Checklist, worked examples and pitfalls. For the logic itself, see Checklist state-based logic for in-app validation.
At a glance |
|
Who can do this | Set up: Super Users, or a Role with Checklists › Modify and Schedules › Modify. Review: Super Users, or Results › Validate plus being a Reviewer on the Schedule |
Where | Checklists › a Checklist › Edit › Logic; the Schedule's Compliance section; the Checklists tile in the mobile app |
Works on | Backend (web) to set up. Mobile app to complete and validate. |
Availability | All organizations |
💡 Why this matters: A second pair of eyes only counts if it leaves evidence. Building the reviewer's questions and signature into the same Checklist means the Result shows who did the work, who verified it and when — not just that someone clicked Approve.
When four-eyes is worth it
Every four-eyes check needs two qualified people on hand at the right time. The overhead pays off when an error would be severe:
Safety-critical inspections — restraints, brakes, structural integrity.
Regulatory compliance — checks where auditors expect independent verification.
High-value financial controls — cash counts, vault access.
Incident response — where one person's judgment shouldn't be the final word.
It isn't worth it for routine checks where errors are cheap to fix, or where you can't reliably get two qualified people in place. For training feedback, use the same state-based logic without the four-eyes framing.
What must be in place
The Schedule or Ad Hoc Slot has Mark all results as requiring validation ticked in its Compliance section, so every Result goes to Awaiting Validation.
The reviewer is a Reviewer on that Schedule or Ad Hoc Slot and has Results › Validate, or is a Super User.
The reviewer validates in the mobile app. Approving from Results in the Backend doesn't open the Checklist, so reviewer-only questions stay unanswered.
See How to validate Checklists for the validation setup.
Split the Checklist into zones
A four-eyes Checklist has three zones:
Shared context — Location, equipment IDs, timestamps. No state-based logic, so both people see it.
Assignee zone — measurements and findings. Logic Based on the checklist state, not equal to Awaiting Validation.
Reviewer zone — the reviewer's own checks and sign-off. Logic Based on the checklist state, equal to Awaiting Validation.
Keep the reviewer zone light. The reviewer verifies what was captured and adds their own checks; if the zone repeats all the assignee's questions, two separate Checklists would be simpler.
Add the reviewer signature
End the reviewer zone with a Signature Question that has the logic equal to Awaiting Validation, so it appears only while the reviewer validates. It shows the reviewer took responsibility, not just that the Schedule required validation. See Signature Question Type.
Mobaro also records who approved the Result in the Contributors section of the Result's Compliance page. A reviewer-name question next to the signature makes the name visible at a glance on the Result PDF.
🛑 Critical: Mobaro doesn't stop the person who completed a Result from validating it if they're also a Reviewer with Results › Validate, or a Super User. Keep the people who complete four-eyes Checklists out of that Schedule's Reviewers, or the second check exists only on paper.
Worked examples
Lap-bar restraint check: a pre-opening Checklist on a Calendar Schedule that requires validation. Shared: train ID, date, weather. Assignee: restraint checks per car, lock measurements, a photo. Reviewer: independent check of one car, sign-off, signature and name.
End-of-day cash count: Shared: date, Location, register IDs. Cashier: denomination breakdown, total, deposit slip number, bag-seal photo. Manager: independent total, seal check, signature.
Incident review: Shared: date, time, Location, equipment, witnesses. On-site operator: observations, photos, notes. Safety reviewer: assessment, root cause, corrective actions, signature.
Pitfalls to avoid
No validation requirement — Results are preapproved and never reach Awaiting Validation, so reviewer-only questions never appear. Test by completing a Result and checking it waits for validation.
Validating from the Backend — approving in Results skips the reviewer zone. Reviewers must validate in the mobile app.
No signature — without it, all you have is "User X approved".
Rubber-stamping — ask reviewers to verify something themselves ("measure car 3"), not just confirm the assignee did it.
Four-eyes everywhere — on low-risk checks it adds overhead without benefit.
Best practices
Reserve four-eyes for checks where independent verification really matters.
Add User Groups of qualified reviewers as Reviewers, and keep assignees out of them.
Keep the reviewer zone short: verification, exceptions and signature.
Frequently asked questions
How do I set up a two-person approval for a checklist?
Each Result gets one approval, so build the second check into the Checklist: give the reviewer's questions logic equal to Awaiting Validation, require validation on the Schedule, and make the second person a Reviewer. They answer those questions while validating in the mobile app.
Can two people sign one checklist with only one person logged in?
Yes. Add two Signature Questions; anyone can sign on the device. Mobaro records only the logged-in User as the person who completed it. For a verified second person, use a reviewer-only Signature Question signed while that Reviewer validates.
Can the reviewer change the answers?
Yes, answers to questions they can see while validating in the mobile app. Changes to existing answers are recorded in the Result's history. See Checklist state-based logic for in-app validation.
Can Mobaro stop the same person completing and approving a checklist?
No. Anyone who is a Reviewer on the Schedule and has Results › Validate, and any Super User, can validate — including the person who completed it. Keep assignees out of the Reviewers list.
What if the reviewer disapproves? Does the assignee redo the checklist?
Not automatically. The Result is marked Disapproved and stays on record; it can still be approved later. If the work must be redone, schedule a new Ad Hoc Slot or wait for the next slot.