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.
- 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.
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.
- LiveKit — Carries live push-to-talk audio between people on a site. Wherever the configured LiveKit server is.
- 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.
- Apple Push Notification service — Delivers push notifications to iPhones and iPads. Apple'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.
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.
- LiveKit — Carries live push-to-talk audio between people on a site. The audio while the channel is open. Where: Wherever the configured LiveKit server is.
- 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.
- Apple Push Notification service — Delivers push notifications to iPhones and iPads. The device's push token and the text shown on the notification. Where: Apple'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.
- Integrations your organisation connects — Xero, Astute Payroll, Zeil, LeedSafe, Akahu, Finpower, Intersoft, 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 15 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.
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.
Activity summary
- What it reads
- A worker's recorded activity on site — sign-ins, tasks and reports.
- What it produces
- A summary of what happened.
- Who decides
- A supervisor reads it. It changes nothing on its own.
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.
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 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.
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.
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.