Overview
RideOps brings ride operations into Mobaro with a tablet-first interface for Operators and Attendants. This article walks through the complete setup for a single Location — from enabling Operational Logging through configuring Operators, Checklists, Queues, Dispatches, Positions, and the widgets that appear in the RideOps app.
Why this matters: RideOps configuration is per-Location. Settings made here only apply to the Location you are editing — repeat this process for every ride you want to bring into RideOps.
Step 1: Enable Operational Logging
Navigate to Locations
In the Mobaro Backend, go to Locations and select the Location you want to bring into RideOps.
Enable Operational Logging
Click Edit on the Location, then scroll to the Operational Logging section and check Enable Operational Logging.
Save
Save your changes before continuing. The RideOps section becomes available once Operational Logging is on.
Note: Operational Logging is required for RideOps to function. See Utilizing Operational Logging for details.
Step 2: Enable RideOps
With Operational Logging enabled, scroll to the RideOps section on the same Location and check Enable RideOps. Save the Location to unlock the full RideOps Settings dialog described in the rest of this article.
Step 3: Configure Operators
Open the RideOps Settings dialog and find the Operators column. Operators are the Users responsible for opening, dispatching, and closing the ride.
Add Operators
Add individual Users or User Groups who can operate this Location. You can mix individuals and groups freely.
Heads up: Adding a User Group as an Operator grants every member of that group operating access to this Location, regardless of normal Location membership. If you only want a subset of a User Group to operate this ride, add the relevant Users directly instead.
Set Required Competencies
Under Required Competencies, add any Competencies Operators must hold to operate this ride (for example, Coaster Operator or Junior Operator Certification). Operators must have an active Certification covering every Competency listed here.
Best practice: Tie Required Competencies to your Certification Processes so RideOps access automatically reflects training records. Operators with expired Certifications will lose access on the same day expiry hits.
Step 4: Configure Checklists
Preopening and Closing Checklists bracket every operating day for the ride. Both are optional, but most parks use at least the Preopening Checklist.
Preopening Checklist
Select a Checklist in the Preopening Checklist field. Operators must complete this Checklist before they can open the ride.
Preopening Checklist Validity (minutes) — How long a completed Preopening Checklist remains valid. After this time, RideOps prompts the Operator to complete it again. Default is 720 minutes (12 hours). For a ride that opens for a single shift, leave this at the default; for 24/7 operations, you may want a shorter window.
Require Approval for Preopening Checklist — Check this to require a supervisor or qualified User to approve the Preopening Checklist before the ride can open. Approval is granted from the Results page of the completed Checklist.
Closing Checklist
Select a Checklist in the Closing Checklist field. Operators must complete this Checklist when closing the ride at the end of the operating day.
Enable closing time reminder — When checked, RideOps reminds the Operator to close the ride if it is still open past the Location's scheduled close time.
See also: Configuring Checklists for RideOps walks through Checklist authoring conventions specific to ride operations.
Step 5: Configure Queues
The Queues column controls how Operators report wait times.
Maximum Queue Time — The longest wait time, in minutes, an Operator can post for this ride. Default is 60. Increase this only for rides where queues regularly exceed an hour (for example, marquee coasters during peak season — try 120 or 180).
Queue Time Step Size — The increment, in minutes, between selectable queue values. Default is 5. A smaller step size gives more precision; a larger step size makes the input faster on a tablet.
Queue Time Update Warning Threshold — How many minutes can pass between queue time updates before RideOps warns the Operator. Default is 15.
Step 6: Configure Dispatches
The Dispatches column captures the throughput characteristics of the ride. Two unit-of-measure modes are available.
Define dispatchable units
Number of dispatchable units — How many cars or trains the ride runs simultaneously (for example, a coaster with two trains running = 2).
Capacity per dispatchable unit — How many riders fit in a single car or train (for example, a 4-row, 4-across train = 16).
Choose Seconds/Dispatch or Riders/Hour
Use the tab control at the top of the Dispatches column to switch between the two input modes:
Seconds/Dispatch — for rides where you measure cycle time in seconds (most coasters, flat rides).
Riders/Hour — for rides where THRPT (throughput) is the working metric (water rides, slow-load attractions). Mobaro converts entered values back to seconds/dispatch internally.
Set dispatch targets
Time between dispatches — Your operational target for the gap between dispatches. Operators see this as the benchmark in the RideOps app.
Ideal time between dispatches — The best realistic gap on a perfectly running day. RideOps uses this as the upper-bound for performance scoring.
Dispatch Update Warning — Number of minutes RideOps will wait between dispatch entries before warning the Operator. Default is 15.
Minimum time between dispatches — The shortest gap, in seconds, between two dispatches that RideOps will accept. This prevents misclicks from registering as impossibly fast cycles.
Enable Delayed Dispatches (optional)
Check Enable Delayed Dispatches to let Operators flag a dispatch as delayed and select a reason (for example, Guest assistance, Mechanical hold). Delayed Dispatches feed into Downtime and operational reporting.
See also: Managing Queues and Dispatches in RideOps covers operator-facing usage.
Step 7: Configure RideOps options
The RideOps Configuration column controls custom messages, statistics access, the close-of-day flow, and the widgets that appear inside the RideOps app.
Custom messages
Two rich-text fields let you tailor the messaging Operators see when the ride cannot operate:
Message when the ride is not ready for operation — shown when prerequisites (Operational Logging, Operator login, etc.) are not met. Use this to direct the Operator to the right escalation path.
Message when the ride has no CFO checks — shown when no Critical-for-Operation Checklist results exist for the ride. Use this to direct the Operator to a supervisor.
Tip: Reference the team and extension Operators should call rather than the individual on duty. The message stays accurate when staffing rotates.
Allow Operators to view Ride Statistics
Check this to give Operators access to Ride Utilization, Dispatches, and Throughput charts inside the RideOps app. Helpful for rides where the Operator is also responsible for hitting throughput targets.
Close-of-day inputs
Allow inputting dispatches when closing the location — When checked, the closing flow asks the Operator to confirm or correct the total dispatches for the day. Useful when manual count-backs differ from logged dispatches.
Allow inputting total riders when closing the location — When checked, the closing flow asks for the total ridership figure for the day. Useful when riders are counted by a turnstile rather than the dispatch widget.
Lock RideOps app configuration
Check this to disable in-app customization for Operators. Anything you set in this dialog becomes the source of truth — Operators cannot override it from the RideOps app.
Watch out: Lock the configuration only after you have validated the settings with a real Operator. Once locked, Operators cannot adjust widgets, sounds, or input modes themselves and will need to reach a supervisor for changes.
Show queue time widget
When checked, the queue time widget appears in the RideOps app, allowing Operators to update wait times. Turn this off for rides where you do not publicly post queue times (back-of-house attractions, employee-only experiences).
Show rider dispatch widget
When checked, Operators can dispatch riders directly from the RideOps app. The widget has four sub-settings:
Rider dispatch input type — choose
Gridfor a number-pad style selector, orSpinnerfor a +/- counter input. Grid is faster on tablets; Spinner is best used for rides with larger capacities (e.g., trains, theatre shows, etc.).Maximum riders per dispatch — the largest rider count an Operator can assign to a single dispatch. Set this to your unit capacity from Step 6.
Number direction —
AscendingorDescending. Controls how the grid is laid out. Most parks pick the direction that puts the most-common rider count under the Operator's thumb.Rider dispatch metric type — what the Operator counts on each dispatch (riders, groups, etc.).
Step 8: Configure Positions and Attendants
Positions describe the physical or functional roles around a ride — for example, Greeter, Grouper, Front Load, Rear Load, Station Assist, Unload. Attendants are the Users (or User Groups) qualified to staff those Positions.
Create a Position
In the Positions column, click Add Position. The Configure Position for location dialog opens.
Provide:
Name — the Position's label inside RideOps (for example, Front Load).
Description — a short summary visible to Operators when assigning Attendants.
Mandatory — when checked, the Location cannot open until an Attendant is assigned to this Position. Use this for safety-critical Positions only.
Required Competencies — which Certifications an Attendant must hold to staff this Position.
Click Save. Repeat for every Position around the ride.
Assign Attendants
In the Attendants column, add the Users or User Groups qualified to staff Positions on this ride. The list applies to all Positions; per-Position eligibility is enforced through the Required Competencies you set in the Position dialog.
Heads up: As with Operators, adding a User Group as an Attendant grants every member of that group access to this Location, regardless of normal Location membership.
Step 9: Create a RideOps Key
A RideOps Key is the credential a tablet uses to log into the RideOps app. One Key can cover one or many Locations.
Navigate to Configuration > RideOps in the Mobaro Backend.
Click
+ Createand give the Key a clear name (for example, Coaster Plaza Tablets).Optionally limit the Key to specific Locations, or allow Operators to switch between Locations on the assigned list.
Click
Save.
Recommendation: Use one Key per area of the park rather than one Key per ride. It cuts Key management overhead while still keeping access scoped sensibly. See Creating and Managing RideOps Keys.
Step 10: Test your RideOps setup
Before going live with Operators, run a test pass:
Log in with a test Operator account and complete the Preopening Checklist.
Open the ride, dispatch a few times, update the queue time, and assign at least one Attendant to a Position.
Close the ride and complete the Closing Checklist (and dispatch/rider confirmation if you enabled those).
Open the Operational Log from the Location's overview and confirm that opens, dispatches, and the close are all recorded with correct timestamps.
Test Competency enforcement: log in with a User who lacks a Required Competency and verify they are blocked.
Next steps
With the basic setup complete, you can layer on:
Custom Positions and descriptions for the RideOps app.
Downtime Templates and follow-up Assignments tied to specific causes.
Create Note Templates to log findings, send notifications, or create follow-up Assignments.
Reporting Dashboards for Ride Utilization, Throughput, and Dispatch performance.
Frequently asked questions
Q: What is the purpose of Operational Logging?
A: Operational Logging records the lifecycle of a ride — opens, closes, dispatches, queue updates, downtime — and gives you an audit trail for performance analysis and compliance reporting.
Q: Can I disable Operational Logging after enabling it?
A: No. Operational Logging is a hard requirement for RideOps and cannot be turned off while RideOps is in use on the Location.
Q: Do I have to use both Preopening and Closing Checklists?
A: No. Both Checklists are optional and configured independently. Most parks run a Preopening Checklist at minimum.
Q: What is the difference between Seconds/Dispatch and Riders/Hour?
A: Both describe the same throughput in different units. Seconds/Dispatch is the time gap between dispatches; Riders/Hour is the implied throughput given that gap and your unit capacity. Pick whichever your ops team naturally talks in — Mobaro converts internally either way.
Q: When should I lock the RideOps app configuration?
A: Once you have settled on the right widgets, dispatch input mode, and rider counts for the ride. Lock it before rolling out to production Operators so the configuration cannot drift through in-app changes.
Q: Can Attendants be required at certain Positions?
A: Yes. Toggle Mandatory on a Position to block ride opens until an Attendant is assigned. Reserve this for safety-critical Positions to avoid blocking opens unnecessarily.
Q: How can I ensure only certified Users operate rides?
A: Add the relevant Competencies under Required Competencies for both Operators and individual Positions. Users without an active Certification covering those Competencies will be blocked at login or assignment.
Q: Can one RideOps Key cover multiple Locations?
A: Yes. Assign multiple Locations to a single Key and toggle Allow Operators to switch between Locations if you want Operators to move between them on the same tablet.
Q: What devices are compatible with RideOps?
A: RideOps runs on any device that runs the Mobaro mobile app. See our Recommended Devices Guide for current device specifications.