Privacy notice

What we store, and where

Your sign-in credentials and session are managed by our authentication system (Better Auth). Your organisation’s operational data — clients, sites, assets, visits and the like — is held in a PostgreSQL database and isolated per organisation by row-level security, so one organisation can never read another’s records. Files you upload, such as your organisation’s logo, are kept in object storage (Cloudflare R2).

Live location while on shift

When a technician checks in on a job — on the way, arrived, or completing work — that check-in updates their current location on the dispatch map, as part of carrying out the assigned work. Separately, if your organisation enables it, technicians can also turn on live sharing to keep that location continuously fresh. Live sharing is opt-in and off by default: nothing extra is shared until a technician turns it on for themselves, and they can pause or stop at any time. While it is on, updates happen only while the app is open and the technician is on an active job — not on days off, breaks, or when the app is closed — and they can also send their location on demand. Each update stores a single current position (coordinates and accuracy) that replaces the previous one. Turning live sharing off stops the continuous updates, but routine job check-ins still update the last position, which stays on the map until it goes stale, is replaced by a later update, or is erased through an operator-assisted request.

We also keep a historyof the positions recorded — both those sent while live sharing is on and those recorded routinely when a technician starts travelling to a job, arrives, and leaves, which happens whether or not live sharing is switched on — so that a completed job can be checked back on later. That history is kept for a limited period — 90 days by default, and your organisation may have set a different one — and is then deleted automatically. Administrators at your organisation can view a technician’s recorded history, and every time they do so is itself recorded. A technician can ask for their history to be cleared sooner, and it is removed in full when a deletion request is carried out.

The “find my tenant” recovery page

When you use the “find my tenant” recovery page, we look up your email address against an internal directory. Your email is not stored as plaintext in that directory — it is stored as a one-way fingerprint (a SHA-256 hash). This protects the directory contents against direct exposure if our database were ever copied without authorisation. Rate limits and abuse detection on the recovery page provide additional protection against scraping or enumeration. Your full email address is preserved separately by our authentication system (Better Auth) so we can send you sign-in links and account messages.

We also keep a record of each use of the recovery page, so that we can tell afterwards whether someone has been probing it for valid addresses. That record holds the date and time, the same one-way fingerprint of the email address, whether the lookup found a match, and the network your request came from — kept only as a coarse range covering many devices, never your exact address. Records of your use of the recovery page are deleted automatically after 30 days. They are never used to contact you.

Access, correction, and erasure

We do not yet offer a self-service way to export or erase your data from within the application. Requests to access, correct, or erase personal data are currently handled by our operators directly — an operator-assisted process. To make a request, contact your organisation’s administrator or your usual support channel.

Cookies and analytics

We use only the cookies necessary to run the service — principally to keep you signed in. We do not use third-party advertising cookies. Any product analytics we use to understand reliability and onboarding respects your browser’s Do Not Track (DNT) setting.

When you sign in

Each successful sign-in is written to your organisation’s audit log, along with the date and time, the method you used — a password, a sign-in link, a passkey or a second factor — and the network (IP) address your device connected from. Administrators of your organisation use this to see who has been signing in and to look into suspected misuse of an account. Unsuccessful sign-in attempts are not recorded.

A network address can indicate roughly where a device is connecting from, so we treat these entries as personal data. The audit log is append-only by design — entries cannot be altered after they are written, which is what makes it dependable as a record. The same property means sign-in entries, including the address, are kept indefinitely and cannot currently be removed on request. If that matters to you, raise it with your organisation’s administrator before signing in.