The driver app

An account provisioned with a temporary password can sign in, read its own profile, change its password and sign out — nothing else. Every other request is refused until a new password is set. Have the driver complete the password change; the block clears on the next sign-in, because the flag travels in the session token.

The app refreshes the session in the background and retries a rejected request once. When that refresh fails it signs the driver out rather than leaving them on a screen that will never load. Repeated sign-outs usually mean the account is locked, suspended or was deleted, so check the user in the dashboard before blaming the phone.

Signing out also unregisters the device from push notifications, which is why a driver in a sign-out loop stops getting alerts as well.

Trip access is checked per driver, and a driver who is not assigned gets "not found" rather than "forbidden" — deliberately, so the app never confirms the existence of another driver’s work. If the driver insists the trip is theirs, open the trip and check the driver field. Both the primary and the secondary driver slot grant access; anything else does not, so a driver expected to pick the work up rather than be assigned it will not see the trip until they are on it.

A trip can only be started from assigned. A trip still in draft or scheduled has to be moved along on the dashboard first.

If the trip is assigned and the start is still refused, check the trip start mode at Customization → Operations → Trip lifecycle. Set to Automatic, a manual start by the driver is rejected and the trip is expected to start on departure from the origin instead.

Drivers appear on the map from their trip GPS while a trip is en route or paused. Seeing every clocked-in driver, including those between trips, is the driver live presence capability, and it is off by default. If you expected an idle driver to show, that is why.

Off-trip presence also reports far less often than trip tracking — minutes rather than seconds — because the point is battery life, not a live trail.

This is deliberate. The app shows a plain-language disclosure before it ever asks the operating system for location, and if the driver declines either the disclosure or the OS prompt, the trip still starts — without GPS. A driver who cannot start a trip is worse than a trip with no trail.

The fix is on the phone: grant location access to Cooriroo in the device settings, then restart the trip tracking. Declining the disclosure is not remembered, so it is offered again on the next start.

Points are captured every few seconds, held in a local buffer and uploaded roughly every ten seconds in batches. Nothing is deleted from the buffer until the server has accepted it, so a tunnel or a dead spot produces a gap followed by the whole stretch arriving together.

The buffer holds a few hundred points — around forty minutes of driving. Beyond that the oldest points are dropped, so a driver who spends an hour with no signal will have a genuinely missing early section.

Check these in order:

• The arrival radius. Tune it at Customization → Operations → Geofence, where the preview shows the circle against your map.
• Dwell time. Arrival is confirmed only after the vehicle has been inside the radius for the configured number of seconds.
• The stop’s status. Automatic arrival only fires for the next stop while it is en route or approaching.
• GPS. A position of exactly zero latitude and longitude means "no fix" and is ignored rather than treated as a location in the Atlantic.

The driver can always mark arrival manually if the geofence does not fire.

On recent Android versions, asking again for background location does not show an in-app dialog — it opens the system Location settings screen. Doing that on every map open would be unusable, so the app asks once and does not repeat it.

A driver who chose "Allow only while using the app" must change it themselves in the device app settings, to "Allow all the time".

Push registration runs at sign-in. If the driver declined the notification permission, or the device could not produce a token, registration stops there and nothing is shown — the app does not nag. Grant notifications in the device settings, then sign out and back in to re-run registration.

On the dashboard side, a send with no registered devices is recorded as sent with zero successes, not as a failure. If the notification log shows sends but the driver has nothing, an unregistered device is the likely cause.

Tokens that the provider reports as permanently invalid are deactivated so later sends do not waste attempts on them; this happens after an uninstall or a long period offline. The app listens for a replacement token and re-registers automatically, but signing out and back in forces it.

Also check that the driver is actually signed in. Signing out unregisters the device, so a driver who logged out at the end of a shift receives nothing until they log back in.

The PIN is set on the task and emailed to the contact when the trip first starts. Three incorrect entries lock the task, and further attempts return a locked result rather than another chance.

If the PIN never arrived, check the contact email on the task — a task with a PIN proof but no valid contact is skipped when the emails go out. If the task is locked, an admin can waive the PIN proof so the driver can complete the delivery. Re-verifying an already verified PIN is safe and does not consume an attempt.

The message names which one. In order of how often it comes up:

• Required checklist items are still unticked — the count is in the message.
• A required proof is missing. Signature, photo, PIN, recipient name and notes are each checked separately, and the message lists the ones still outstanding. An admin can waive a proof method if it genuinely cannot be captured.
• The stop enforces task order, so an earlier task has to be completed or skipped first. The message names that earlier task.
• Required tasks cannot be skipped at all, only completed or failed.

If a photo or signature is refused on upload, it is the file rather than the task: uploads are checked against a maximum size and a list of accepted image types, and the message states both.

Work done with no signal is queued on the device and drained when the connection returns. Ask the driver to open the Sync Status sheet: it shows what is still queued, lists conflicts, and has a Sync Now action. "All synced" means the phone has nothing left to send and the problem is elsewhere.

Conflicts appear when the trip was changed on the dashboard while the driver was offline. The app retries once with a refreshed version, and if that still conflicts it moves the action to the conflicts list rather than overwriting your change. Those actions have to be redone — either by the driver in the app, or by you on the trip.