How RoverDrop works

Getting started

Create your firm's account. The person who creates it becomes the administrator. Add your team on the Settings page. There are three roles:

• Field submits packets and tracks them in My Submissions.
• Office does everything Field does, plus accepts, files, reassigns, and views reports.
• Admin does everything Office does, plus manages users, jobs, and settings.

There is no self-signup within a firm. Accounts are created by the administrator, so the user list stays under your control.

Users can add a passkeyfrom their account page and sign in with their device's fingerprint, face, or PIN instead of a password. Passkeys use WebAuthn: authentication happens on the device and only a public key is stored on our side, so there is no password to phish. Passwords and any configured single sign-on keep working alongside passkeys.

Submitting a packet

The form has three fields: title, cover sheet, files. An optional job number tags the packet for filtering and routing. There is no recipient field and no folder to choose. Every packet goes to your firm's single intake queue.

• Files upload directly to storage in resumable pieces. A dropped connection resumes where it left off instead of starting over.
• A packet does not count as submitted until every file is fully uploaded and its size is verified server-side. A SHA-256 checksum is recorded for each file.
• The submitter gets a numbered receipt on screen and by email, and stays responsible for the packet until the office accepts it.
• With no connection at all, the packet is saved on the device and sent automatically when the signal returns. A per-device Send over Wi-Fi only option holds queued packets on cellular until Wi-Fi is available.
• The submitter can attach their device locationto a packet, recording where it was composed. An administrator can require location on every packet (see below). Coordinates are reported by the submitter's device — like camera EXIF data, they are verification context the office can check work against, not independent proof of where someone stood.
• Nearby-job suggestion:when location is on, the composer compares the device's position against where the firm's prior packets were composed and offers the closest matching job as a one-tap fill for the job-number field. It is only ever a suggestion — nothing is filled in silently — and it kills the mis-keyed job number without any geofence setup.

Submission requirements

An administrator can set rules that a packet must meet before the crew can send it, as a firm-wide default and as per-job overrides on the Settings page:

• a minimum number of files or photos;
• required file types (for example, at least one .csv);
• a required cover sheet or job number;
• a checklist the submitter must confirm, recorded on the packet;
• required device location, attached with no opt-out.

Requirements are enforced when a packet is composed and submitted in the app. Packets that arrive by email intake are not checked, since an email can't confirm a checklist.

Photos, voice notes, and previews

• Photos show as a thumbnail grid with a full-size viewer. For each photo, RoverDrop reads the camera metadata — capture time, camera model, and GPS coordinates when present — from the file and shows it alongside. Images, PDFs, and text-based data files (CSV, TXT, DXF, GPX, logs) can be previewed in place without downloading.
• Annotation: mark up a photo with arrows, boxes, text, and freehand drawing. The markup is saved as a new file linked to the original; the original is never altered, so the evidentiary copy stays intact.
• Voice notes: record a spoken note in the composer and attach it to the packet. It plays back in place, on the packet, for anyone who can access the files.

Accepting, returning, and filing

The intake queue shows every packet with its status, submitter, and how long it has been waiting. Unaccepted packets sort to the top, oldest first, color-coded by age.

• Accept transfers responsibility to the acceptor, by name. Downloading files never transfers responsibility; it is logged but non-custodial.
• Mark filed records that the files were placed in their final destination. This is the done state that reports measure against.
• Reassign moves responsibility to another office user, who is notified by email.
• Return for correction sends a packet back to the submitter with a required reason instead of accepting it. The packet moves to a Returned state and the submitter is emailed a link to fix it and resubmit the same ticket — every edit is recorded on the packet, and archive copies of the original files are kept. The office can undo a return.
• Both accept and filed can be undone, with an optional reason. Undo is recorded in the audit trail and the affected person is notified. History is never rewritten.

Sign-off signatures

A firm can ask for, or require, a drawn signature when a packet is accepted or filed, set separately for each step on the Settings page. The signature is captured on a pad in the accept or file action, stored with that custody event, and shown in the audit trail — so a transfer of responsibility can carry the responsible person's actual signature.

Sharing with clients

Office and admin users can create a share linkto give someone without an account — a client, adjuster, or subcontractor — access to one accepted or filed packet's files and details.

• A link expires after a set period (1 to 365 days) or never, and can be revoked at any time.
• An optional passcode adds a second factor for links sent by email.
• The recipient sees only that packet's title, notes, and files — nothing else about your firm.
• Every open and download through the link is recorded in the packet's audit trail, so the chain of custody continues to the final recipient.
• The page carries your firm's name — and your logo, once an administrator uploads one under Settings → Organization. The same branding appears on file-request pages.

File requests

A file-request linkis the share link's inverse: it lets someone outside the firm — a subcontractor, a testing lab, an independent adjuster — send files into your intake queue without an account, instead of emailing them or dropping them in an open folder. Office and admin users create them on the Requests page.

• The outside sender opens the link, types their name, attaches files, and sends. Their upload uses the same resumable, direct-to-storage engine as the field app — multi-GB files and dropped connections are fine — and every file is size-verified and SHA-256-checksummed on arrival, then archived write-once.
• What arrives is a normal packet in the queue, flagged externaland carrying the sender's typed name in the header, the receipt email, and the audit trail. The link's creator holds responsibility until someone accepts, so an external delivery is never ownerless.
• A link can be pinned to a job (everything sent through it lands there), given an expiry (1 to 365 days, or never), protected with a passcode, and revoked at any time. The Requests page shows each link's opens and packets received.
• The sender sees an upload page with your firm's name and logo — never your queue, other packets, or anything else about the firm.

Supplements and comments

Until the office accepts a packet, the submitter can still edit it — notes and files — with every change recorded on the packet. Acceptance locks it. To correct or add files after that, use Send a supplement on the packet page: it creates a new packet linked to the original in both directions.

Comments on a packet are emailed to everyone involved: the submitter, the current responsible person, the acceptor, and prior commenters. Comments live in the packet record instead of a reply-all thread.

Legal hold

A legal hold keeps working copies regardless of the firm's retention setting — for a dispute, claim, or litigation. An administrator places or releases a hold per job in the Settings job list; every packet under the job is covered, including packets submitted while the hold stands. When a matter touches a single submission — or a packet has no job number — an admin can instead hold just that packet, from the audit-trail panel on its page. Either way the change is stamped into the covered packets' audit trails, every held packet shows the hold on its page, and the archive copy is kept regardless. Holds are admin-only on purpose: they suspend the firm's retention policy, which is a management decision, not a queue action.

Notifications

• New packet: the office group is emailed; the submitter gets a receipt.
• Aging reminders: packets unaccepted past a threshold (default 4 hours) trigger escalating emails until someone accepts. Thresholds are set on the Settings page.
• Daily digest: one email summarizing everything open.
• Routing rules: Admin can route a job number to a specific person, who gets a direct email when a matching packet arrives. Anyone can still accept.
• Push notifications:every alert above (except the digest) can also land on a phone or desktop's lock screen as a standard web push — new and overdue packets for the office; returned packets, acceptances, and comments for the crew. Opt-in per device under My Account, so a crew member can turn it on for their phone without touching email. On iPhone and iPad, add RoverDrop to the home screen first (an Apple requirement for web push).

Email intake

Each firm has a private intake address, shown on the Settings page. Email sent to it becomes a normal packet: subject is the title, body is the cover sheet, attachments are the files. Only mail from an active user's address is accepted. This is a bridge for crews who still work from their inbox; the receipt, custody, and archive behavior is identical.

Reports and map

The Reports page (office and admin) shows median time-to-accept and time-to-file, an aging breakdown of unaccepted packets, weekly submission volume, and the longest-waiting open packets, over 7 to 365 day periods.

The Map page plots every open packet that carries a composed-at location, pinned and colored by status, so a dispatcher can triage work geographically. Packets appear on it only when the submitter attached their location.

API

Admins create read-only API tokens on the Settings page. The token is shown once. Use it as a bearer token:

curl -H "Authorization: Bearer rd_..." \
  "https://your-roverdrop-host/api/v1/packets?status=submitted&limit=50"

• GET /api/v1/packets lists packets. Filters: status (submitted, accepted, returned, filed), since (ISO date), limit (max 500).
• GET /api/v1/packets/<id> returns one packet with its files (names, sizes, SHA-256 checksums) and full audit trail.

Tokens are scoped to your firm and can be revoked at any time.

Webhooks

Set a webhook URL and signing secret on the Settings page. RoverDrop POSTs a flat, signed JSON payload on every packet event — submitted, accepted, filed, returned, reassigned, and their undos — built for direct field mapping in Zapier, Make, and Power Automate as well as your own systems.

See the full webhook reference for the event catalog, a sample payload, signature verification code, and a step-by-step Zapier walkthrough.

Security and storage

• File bytes go directly from the browser to object storage over TLS; they do not pass through the application server.
• Every file gets a SHA-256 checksum and a server-side size verification before the packet counts as submitted.
• As soon as a packet is submitted, every file is copied to write-once archive storage (locked against deletion and overwriting). Retention rules remove working copies later; the archive copy is always kept, and a legal hold keeps the working copies too.
• Each firm's data is isolated: queries, files, and API tokens are scoped to the firm. Passwords are hashed with bcrypt, and passkeys store only a public key on our side. Sessions expire after 14 days idle.
• The audit trail is append-only. Undo actions add events; nothing is deleted or rewritten.

Questions not covered here: support@roverdrop.com