Legal

Privacy policy

Last updated: 4 October 2026

This policy explains what personal information Workhr collects, why, where it lives, and the choices you have. The short version: your records are stored in Australia and your agency owns them, a few processing steps are sent to providers outside Australia and we name each one and say where, we never sell personal information, and location is captured only at the moment a worker clocks in or out.

Who we are

Workhr (workhr.app) is a workforce management platform for labour-hire and recruitment agencies in New Zealand and Australia, operated by AiTearoa (“we”, “us”). For anything in this policy, contact us at privacy@workhr.co.nz or via workhr.app/contact.

Our role: mostly a processor

Most personal information in Workhr belongs to our customers — the agencies. When an agency stores candidate profiles, worker timesheets or client contacts in Workhr, that agency is the party responsible for the information, and we process it on their instructions. If you are a candidate or worker and want your information corrected or removed, the fastest path is your agency; we give them the tools to do it (including full erasure).

We act in our own right only for the information we need to run the service: your login account, billing details for our customers, support conversations, and basic usage of our marketing site.

What we collect

Account information — name, email address, role, and authentication events.
Workforce records entered by your agency — candidate and placement details, CVs, credentials and licences, shifts, timesheets, pay and billing records.
Location at clock-in and clock-out — when a worker signs in or out of a site through the worker app, we record GPS coordinates and accuracy at that moment, and the distance from the rostered site. We do not track location in the background — only at the moment of a punch, and workers can decline GPS (the punch is then flagged as location-unavailable rather than blocked).
Content you upload — documents, photos and videos shared inside the platform (for example on the team feed), and meeting recordings where your organisation uses the meeting recorder, together with their transcripts.
Service and device data — logs, IP addresses, and the pages and features used, for security and to make the product better.
Criminal record checks — where an agency runs a Ministry of Justice check, an NZ Police vet or an Australian National Police Check, Workhr records the worker’s consent (the exact words they were shown, in the language they read them in when they gave it in the worker app), who requested and submitted the check, and the outcome: whether anything was disclosed and, if so, the agency’s decision and its reason for the role. We do not store conviction details, and a check result is never shown to the agency’s clients. A Ministry of Justice check leaves out convictions concealed under the Clean Slate scheme, and nothing in Workhr asks a worker to disclose one.
References — the referee’s name and contact details, which the candidate or the agency gives us, and the referee’s answers. Referees are told, before they answer, who is collecting the information, why, that a summary may reach the client, and that the candidate may ask to see it. A reference is used for the placement decision it was given for.
Professional profiles collected from somewhere other than you — where an agency uses Workhr’s sourcing tools, we bring back public professional profiles from a third-party index: name, headline, current and past job titles, employer, city and country, self-reported skills and certifications, and the link to the public profile itself. The people in those results have not applied to anything and may never have heard of the agency. They are held as a sourcing record, not as a candidate: nothing promotes one into an agency’s candidate database on its own. If you are one of them and want your record removed, write to us and we will route it to the agency holding it.

The Workhr app on iPhone and Android

The app shows the same worker portal as workhr.app, so everything above applies to it. On the phone it also uses:

Location — only while the app is open, and only to record where you were at the moment you sign in or out of a site. The app does not use location in the background.
Camera and photos — only when you choose to photograph or upload something (a timesheet, your ID, your tickets, a hazard).
Microphone — only while you are recording a voice note or voice report.
Notifications — if you allow them, the app registers a push token for your phone so we can send shift and message alerts. Notifications are delivered through the Expo push service and then Apple or Google. Signing out removes the token.
Sign in with Apple — if you use it, Apple gives us your name and either your email address or a private relay address that forwards to it. We use these only to sign you in.
Offline copies — so the app works without signal, it keeps a copy of the pages you use (and anything you sign in or out while offline) on your phone, for at most seven days. A different person signing in on the same phone clears them.

The app has no advertising and does not track you across other companies’ apps or websites. Workhr is for people of working age and is not directed at children under 16.

Deleting your account. In the app, go to Me > Delete account. Without the app, use workhr.app/delete-account. What is deleted, and the pay and safety records the law requires your agency to keep, are set out on that page.

Where your data lives

The database and the application are in Sydney, Australia — AWS ap-southeast-2 via Supabase, served from Fly.io’s Sydney region. Backups stay in the same region. Data is encrypted in transit and at rest. Every record you enter is stored there.

Some processing leaves that region, and we would rather say so than imply otherwise. These are the providers we use that are not pinned to Australia. Speech-to-text is deliberately pinned to Sydney; these are not:

Anthropic — The AI features — see the automated-decisions section for what each one reads. Anthropic's global API endpoint. Not pinned to Australia.
Resend — Delivers transactional email. Not pinned by us.
TNZ — Delivers text messages. api.tnz.co.nz, a New Zealand gateway.
Recall.ai — Sends a notetaker bot into a Zoom, Meet or Teams call when somebody ticks it on a booking. ap-northeast-1, Tokyo. Recordings are held there for thirty days.
Sentry — Records application errors so we can fix them. Set by the configured DSN.
PostHog — Counts which features are used, for product decisions. us.i.posthog.com, the United States, unless configured otherwise.
Stripe — Takes payment from agencies for their Workhr subscription. Stripe's global service.
Browser push services — Delivers web push notifications. The message goes to the push service of whichever browser the person uses — Google, Apple or Mozilla. Set by the person's own browser.
Expo push service — Delivers notifications to the Workhr app on iPhone and Android, passing them on to Apple's and Google's push services. exp.host, Expo's push API in the United States.

How we use information

To provide the service: rosters, attendance, timesheets, payroll and billing.
To power AI features your organisation turns on — for example summarising meetings, drafting CVs, or answering questions over your own data. AI features only see data belonging to your own organisation.
To secure the platform, investigate misuse, and meet legal obligations.
To improve Workhr — using aggregated or de-identified usage data, never the content of your records.

Who we share it with (subprocessors)

We do not sell personal information. We share it only with the service providers that run Workhr, under contracts that limit what they can do with it:

Supabase — The database, sign-in, and file storage. Everything the platform stores, including every uploaded document. Where: AWS ap-southeast-2, Sydney.
Fly.io — Runs the application itself. Every request, and whatever is in it while it is being served. Where: Sydney.
Anthropic — The AI features — see the automated-decisions section for what each one reads. Only what the feature in question sends. Nothing sent is used to train their models. Where: Anthropic's global API endpoint. Not pinned to Australia.
Deepgram — Turns speech into text — meeting transcripts, voice notes, the voice assistant. The audio, and the transcript it produces. Where: Deepgram's Australian endpoint, in Sydney, for everything carrying audio. Account administration goes to their global endpoint and carries none.
Resend — Delivers transactional email. The recipient's address and the content of the message. Where: Not pinned by us.
TNZ — Delivers text messages. The mobile number and the content of the message. Where: api.tnz.co.nz, a New Zealand gateway.
Recall.ai — Sends a notetaker bot into a Zoom, Meet or Teams call when somebody ticks it on a booking. The call's audio and video, and the recording it keeps of them. Where: ap-northeast-1, Tokyo. Recordings are held there for thirty days.
Sentry — Records application errors so we can fix them. The error, the page it happened on, and the account it happened to. Not the contents of your records. Where: Set by the configured DSN.
PostHog — Counts which features are used, for product decisions. Which screens and features were used, and by which account. Where: us.i.posthog.com, the United States, unless configured otherwise.
Stripe — Takes payment from agencies for their Workhr subscription. The paying organisation's billing details. No candidate or worker information. Where: Stripe's global service.
Browser push services — Delivers web push notifications. The message goes to the push service of whichever browser the person uses — Google, Apple or Mozilla. The browser's push subscription and the text shown on the notification. Where: Set by the person's own browser.
Expo push service — Delivers notifications to the Workhr app on iPhone and Android, passing them on to Apple's and Google's push services. The app's push token for that phone and the text shown on the notification. Where: exp.host, Expo's push API in the United States.
Integrations your organisation connects — Firmable, Referoo, Xero, Astute Payroll, Zeil, LeedSafe, Google Workspace, Gmail, Microsoft 365, Outlook. These move data on your organisation’s instructions, once your organisation connects them, and are governed by those providers’ own terms.

Where a feature is off, its provider gets nothing: the notetaker bot is only dispatched when somebody ticks it on a call, and the speech-to-text provider only sees audio your organisation records.

Automated decisions and AI

1 check is made automatically, and neither can turn a person down — the worst outcome is being asked for a better photograph or being passed to a person. In 19 other places a model helps somebody decide: it reads information and produces something a consultant or a client then acts on. You can ask your agency what a model said about you, and ask a person to look again.

Decisions made automatically

These act on their own output. Each one is limited to a decision that can be undone or appealed, and none of them can turn a person down.

Onboarding document check

What it reads: The image or PDF a worker uploads for identity, right-to-work or a licence, and the document type they said it was.
What it produces: Whether the upload is the kind of document that was asked for, whether it is legible, and the fields visible on it.
Who decides: A clear, readable, correct document is accepted automatically. Anything else either asks the worker for a better photo or goes to a consultant — the check never turns a person down.
Never sent to it: Nothing beyond the document itself is sent.

Where a model helps someone decide

A person makes the decision in every case below. The model's output is something they read, and they can disagree with it.

Meeting follow-up email draft

What it reads: The meeting's stored summary, decisions and action items (never the raw transcript), the names of the people in the room, and the tone the consultant picked.
What it produces: A greeting, an opening line, a closing line and up to three 'in short' bullets for the follow-up email; the recap card itself is built from the stored items without a model.
Who decides: The draft opens in the composer for the consultant to edit, rewrite or discard. Nothing is sent, and no task is created, until they press Send.
Never sent to it: The transcript, the recording, and every other record about the attendees.

Inbound email reading

What it reads: The subject, text and sender class of an email that arrives in a connected mailbox (outbound, internal and bulk mail are skipped), and the date it was sent.
What it produces: What the email is for (a meeting request, a reschedule, a CV, a job order, a timesheet, an invoice, or general), any times it proposes, and a one-line summary.
Who decides: The result only labels the message and offers chips in the reading pane. A consultant chooses whether to confirm a time, book a meeting or add a candidate; nothing is sent or created without that click.
Never sent to it: Attachments, the rest of the thread, and any record linked to the sender. Only the one message is read.

Photo evidence check

What it reads: One photo a worker attached to a safety form, downsized, and the one-sentence requirement the form author wrote for that photo (for example "hi-vis and steel caps visible").
What it produces: pass, unsure or fail, with a one-sentence reason, stored against that field of the submission.
Who decides: The verdict never blocks the form. unsure and fail flag the submission for the site supervisor and put it on the compliance desk's awaiting list; a person reads the photo and decides. pass changes nothing.
Never sent to it: The worker's name and record, the other answers on the form, and the site. The model is told not to identify people in the photo.
Model: claude-sonnet-5 (2026-10-01)

Form submission analysis

What it reads: The answers a worker filed on one portal form (signatures and photos named, never read), the form's question labels, its declared safety kind and the site name.
What it produces: A plain-English summary, the answers worth a second look with a reason each, the gaps, and a suggested urgency of low, medium or high — stored on that submission.
Who decides: The verdict never blocks the filing and the model never sets the route: deterministic rules decide the severity floor and are the only writer of the top rung. medium and above opens a corrective action a person must close; high and above also alerts staff. A reviewer reads the submission and decides.
Never sent to it: The worker's wider record, their other submissions, and their pay. Only the one form is read.
Model: claude-sonnet-5 (2026-10-05)

Sourcing shortlist opinion

What it reads: A public professional profile — current and past job titles, employer, city and country, self-reported skills and certifications — judged against the requirements written on the job order.
What it produces: A recommendation of strong hire, hire, maybe or no hire, with the reasons for and against each one.
Who decides: A consultant reads it and decides who to contact. Nobody is contacted, rejected or put on file because of it.
Never sent to it: Name, age, photograph, school, university, graduation year, clubs and interests are removed before the model sees anything. That is this feature's rule and not a promise about the rest of them — the research feature below is given the name deliberately, because it cannot look somebody up without it.
Model: claude-opus-5 (sourcing-judge-v3)

Research on one sourced person

What it reads: The name, job title, employer, city and country and claimed credentials held for one person a consultant has opened, plus whatever a live web search returns about them from public sources.
What it produces: A one-line view on whether they are the right kind of person for the role, a list of claims found in public sources, a list of claims that could not be corroborated, and an opening line — each with the pages it came from.
Who decides: A consultant asks for it one person at a time, reads it, and decides whether to approach them. It rates nobody and writes nothing to a candidate record.
Never sent to it: It is asked never to state or imply anything about right to work, visa status, immigration position, nationality, age, health, ethnicity, gender, religion or family circumstances, and never to use anything behind a login or bought from a broker.
Model: claude-opus-5 (ask-v1)

Reading a sourcing brief into requirements

What it reads: The sentence or job description a consultant typed. No personal information from anyone's record.
What it produces: The requirements it read out of that sentence — titles, tickets, location, years — split into what a person must have and what is merely preferred.
Who decides: The requirements are shown as chips the consultant can remove or demote before the search runs, so a wrong reading is a two-second fix rather than a silent exclusion.

Candidate search in plain words

What it reads: A recruiter's typed question, and — for each candidate the agency's own scoring already shortlisted — their skills, whether they are on an assignment, whether they have worked in the last 60 days, and their town.
What it produces: A shortlist chosen from that scored pool, with a line about each person, and a note when the books cannot fill the brief.
Who decides: A recruiter reads the list and decides who to approach.
Never sent to it: The model is not given the person's name, their right-to-work status, or how long it has been since they last worked — only whether that was inside the last 60 days. Names are shown to the recruiter and withheld from the model.

Client crew search

What it reads: A client's typed question about the workers assigned to them, over the worker records that client is already entitled to see.
What it produces: A filtered list of those workers.
Who decides: The client reads the list and decides who to request.

CV reading at intake

What it reads: The CV a person sends in — their history, qualifications and contact details.
What it produces: Structured fields written onto their candidate record.
Who decides: A consultant reviews the record before it is worked. The extraction fills fields; it does not screen anybody.

Work history extraction

What it reads: A CV's employment section — employers, dates, titles and duties.
What it produces: A dated list of roles held.
Who decides: A consultant reviews and corrects it on the candidate record.

Formatted CV for a client

What it reads: What the agency holds about the candidate — history, tickets, skills — and the role being submitted for.
What it produces: A written CV presenting that person to a client.
Who decides: A consultant reads it and decides whether to send it.

Cover letter

What it reads: The candidate's record and the job being applied for.
What it produces: A covering letter written in the candidate's voice.
Who decides: It is reviewed before it is sent, and can be edited or discarded.

Submission pack

What it reads: The candidate records chosen for a shortlist, and the client's brief.
What it produces: A written pack introducing those people to a client.
Who decides: A consultant chooses who is in it and reads it before sending.

Timesheet reading

What it reads: A photographed or uploaded timesheet — names, dates, start and finish times.
What it produces: Hours proposed against a worker's week.
Who decides: The hours are approved by a person before they are paid or billed. Nothing reaches a pay run unapproved.

Agreement term extraction

What it reads: The text of an employment or client agreement, including the parties named in it.
What it produces: The terms found in it — rates, dates, notice, obligations.
Who decides: A person checks the extracted terms against the document before they are relied on.

Meeting summary

What it reads: A meeting transcript, which may include an interview and anything said in it.
What it produces: A written summary and the actions arising.
Who decides: Whoever ran the meeting reads it. It is a record, not an assessment.

Interview answers and suggested profile updates

What it reads: A meeting transcript, the meeting's agenda questions, and the names of the candidate, client contacts and company it is filed on.
What it produces: A short answer and a verbatim quote per agenda question, and proposed updates to the linked records (skills, tickets and expiries, availability, pay expectation, transport, work history, a right-to-work statement, a contact's job title, notes on the client company).
Who decides: A consultant confirms or edits each answer, and applies or declines each proposed update one at a time. Nothing reaches a record until they press Apply; a right-to-work statement only ever becomes a task to sight evidence. Anything whose quote is not in the transcript is discarded before a person sees it.
Never sent to it: Instructed never to record health, injury, disability, pregnancy, family status, age, ethnicity, religion, political opinion, sexual orientation, union membership, criminal history, or gaps in work history, and never to rate or recommend a person.

Matching people when an agency moves their data in

What it reads: Two records from an agency's old system that look like they might be the same person — the names, contact details and employment details on each.
What it produces: A view on whether they are one person or two, with the reason.
Who decides: It runs only during a supervised migration, only on pairs an exact match had already flagged as uncertain, and the result is reviewed before the import is committed.

Where we can keep something away from a model, we do. For the onboarding document check: Nothing beyond the document itself is sent. For the meeting follow-up email draft: The transcript, the recording, and every other record about the attendees. For the inbound email reading: Attachments, the rest of the thread, and any record linked to the sender. Only the one message is read. For the photo evidence check: The worker's name and record, the other answers on the form, and the site. The model is told not to identify people in the photo. For the form submission analysis: The worker's wider record, their other submissions, and their pay. Only the one form is read. For the sourcing shortlist opinion: Name, age, photograph, school, university, graduation year, clubs and interests are removed before the model sees anything. That is this feature's rule and not a promise about the rest of them — the research feature below is given the name deliberately, because it cannot look somebody up without it. For the research on one sourced person: It is asked never to state or imply anything about right to work, visa status, immigration position, nationality, age, health, ethnicity, gender, religion or family circumstances, and never to use anything behind a login or bought from a broker. For the candidate search in plain words: The model is not given the person's name, their right-to-work status, or how long it has been since they last worked — only whether that was inside the last 60 days. Names are shown to the recruiter and withheld from the model. For the interview answers and suggested profile updates: Instructed never to record health, injury, disability, pregnancy, family status, age, ethnicity, religion, political opinion, sexual orientation, union membership, criminal history, or gaps in work history, and never to rate or recommend a person.

You can ask your agency what an automated system produced about you and ask a person to look at it again. If you cannot get an answer, contact us at privacy@workhr.co.nz.

How long we keep it

Most information is kept for as long as the agency’s account is active, on whatever retention schedule that agency configures. When an agency leaves Workhr, they can export their data; we then delete it from production systems, with backups aging out on a fixed schedule.

Pay and employment records are the exception, and they override the above. Where your agency uses Workhr to run timesheets, pay or payroll, the law requires those records to be kept for a set period — seven years — and we keep them for that period even if a shorter retention setting would otherwise have reached them, and even after the person leaves the agency. The periods come from the Tax Administration Act 1994 (s 22, business and PAYE records, 7 years), the Employment Relations Act 2000 (s 130, wage and time records, 6 years), the Holidays Act 2003 (s 81, holiday and leave records, 6 years) and, for Australian work, the Fair Work Act 2009 (s 535, employee records, 7 years). We apply the longest of them to all of it.

Identity documents sighted for a Ministry of Justice check must be disposed of by the agency 90 days after it sights them — the Ministry’s rule. Workhr shows that date on the check. It does not yet destroy an uploaded copy automatically (see the erasure note below), so the agency removes it as a separate step.

In practice this means our automatic deletion never removes or anonymises someone who was paid through Workhr inside that seven-year window — a wage record has to say who was paid, so an anonymous one would not be the record the law requires. Once the window passes, the normal retention schedule applies again.

What an erasure request does today, precisely. When an agency completes one, we clear the identifying fields on the person’s record: name, email, phone numbers, home address and coordinates, emergency contact, kiosk PIN and any equal-opportunity answers they gave. Documents they uploaded are not yet destroyed by that step — identity, right-to-work and licence scans stay in the agency’s file store and still contain identifying information, and so do the payroll details held under the revenue retention duties above. We are building the document destruction; until it ships, ask your agency to remove uploaded documents as a separate step, and ask us if you want to know what is still held.

Your rights

Under the New Zealand Privacy Act 2020 and the Australian Privacy Principles, you can request access to and correction of your personal information. Where your information is held on behalf of an agency, we will route your request to them and support them in answering it. Contact privacy@workhr.co.nz. If you are unhappy with our response you can complain to the NZ Office of the Privacy Commissioner or the Office of the Australian Information Commissioner.

If something goes wrong

If a privacy breach occurs that is likely to cause serious harm, we will notify affected organisations and the relevant regulator as required by the Privacy Act 2020 (NZ) and the Notifiable Data Breaches scheme (AU), and tell you what happened, what we’ve done, and what you can do.

Cookies

The application uses essential cookies for sign-in sessions. The marketing site uses minimal, first-party analytics to understand page visits. We don’t run third-party advertising trackers.

Changes

We will post any changes to this policy here and update the date at the top. For material changes we will notify account administrators by email.