Overview
Use this guide when RideOps reports a connection problem, an entry is missing from the Backend, or the tablet shows information you do not expect. Separate a connection failure from queued work, the wrong Location, and a delayed external integration.
At a glance |
|
Who can do this | Operators; authorized administrators for configuration and record checks |
Where | RideOps tablet and the matching Location in the Backend |
Works on | RideOps; Backend (web) |
Availability | All organizations |
🛑 Critical: Do not use Factory Reset or clear browser site data while work may exist only on the tablet. Being online does not prove delivery. Do not open a ride or record an invented dispatch to test the connection.
Check the affected tablet
1. Record the message and Location
Note the displayed Location, exact error and time. Compare it with the intended ride. If the tablet is assigned to the wrong Location, follow RideOps tablet settings and the key’s switching rules; do not reset it simply to try another Location.
2. Check the connection
Check whether the tablet has working internet and whether the problem affects other tablets on the same network. Use your approved network support process. A Wi-Fi icon alone does not prove RideOps can reach Mobaro.
3. Distinguish waiting from completion
Record whether the Checklist is waiting to upload or waiting for review. These are different stages. A submitted action is not proof that processing or approval has finished.
Check the expected records
Ask an authorized supervisor to check the same Location and period in the Backend. Compare actual dispatches, queue entries, Notes or Results with the tablet. Use the operational log for the activity types it includes. Do not repeat an entry merely because a summary has not updated.
RideOps has partial offline support. Dispatches, queue times and Notes can wait locally; other actions need a connection. Follow RideOps setup and offline limits rather than assuming every workflow is available offline.
Separate configuration and integration issues
Different widgets can come from local tablet settings or locked Location settings; see tablet settings. If Mobaro has the expected record but a guest app does not, investigate the partner integration and mapping; an enabled integration badge alone does not prove delivery. See integration checks.
Escalate without losing work
Send Support the Location, affected tablets, times and time zone, connection message, record examples and checks tried. Keep the original tablet available. Before replacement, follow preparing a replacement RideOps tablet.
Best practices
Check actual records before resetting or repeating work.
Coordinate any tablet changeover with the operating team.
Treat operational readiness and connection status as different checks.
Frequently asked questions
RideOps is online again. Is it safe to reset the tablet?
Not solely because it is online. Confirm the expected Backend records and preserve unfinished work first. If delivery is uncertain, keep the tablet intact and contact Mobaro Support.
Why does RideOps say uploaded work is awaiting review?
Uploading and review are different stages. The designated reviewer must check the Result through the normal approval workflow. Do not reset the tablet or approve work merely to change a readiness indicator.
Mobaro shows the new queue time but our guest app does not. What should I check?
Check the partner integration, Location mapping and last successful delivery with the integration owner. The RideOps tablet is only one part of that route; see integration troubleshooting.