The Person Your Tooling Cannot See
Our data export and erasure tooling takes a user account. An external ticket requester does not have one — that is the entire reason they were sent a tracking link. So the people most likely to ask are the people the tool cannot be pointed at.
The position, stated first
This is a description of how our software works, not legal advice, and you should take the second from somebody qualified to give it. The software fact is simple: the export and erasure tools are keyed on a user account, and a ticket requester without an account is outside their reach. If you handle requests from people who are not users, that is a manual process today and you should plan it as one.
There is a category of person almost every business system underserves, and it is not a small one: the people who appear in your data without ever having logged into anything.
The requester who is not a user
A support desk in this product can receive a request from somebody with no account. They are emailed a signed link to a page where they can follow the ticket, which is a genuinely good design — it means an external customer can track their own request without being made to register for a system that is not theirs.
That ticket then accumulates their name, their email address, whatever they wrote in the description, whatever the agents wrote back, and any files anybody attached.
And the tooling that takes a user
There is a data export and account-erasure facility in this product and it is real. It assembles a profile, roles, assignments, audit history and privacy state, and it works.
Its entry point takes a user account. Not an email address, not a customer, not a person — an account. So there is no way to point it at somebody who never had one.
Two kinds of person in one system
A user
Reachable
- Has a login and a profile
- Export assembles their record
- Erasure has something to act on
- Audit history is attributable to them
A requester, a customer, a signatory
Outside the tool
- No account, by design
- Identified by name and email on records
- Nothing to pass the export
- Found only by searching, by hand
The codebase already knows this distinction exists — it is written down where handover signatures are described, and those are explicitly people who are usually not users of the system.
The people most likely to ask what you hold about them are the ones who never registered, and account-keyed tooling is pointed exactly away from them.
Where else this shape appears
Once you look for it, the non-user is everywhere in an operations system, and each instance is a place a name and a contact detail live outside the reach of anything account-shaped.
| Where a non-user appears | What is held | Reachable by account tooling |
|---|---|---|
| An external ticket requester | Name, email, correspondence, attachments | No |
| A person who signs for a delivery | Name and a signature image | No |
| A supplier contact | Name, email, phone | No |
| A customer contact on an invoice | Name, email, address | No |
| A job applicant or partner enquiry | Whatever the form collected | No |
| An employee with no login | Full employment record | No |
The last row is the one that surprises people, and it is a deliberate design in this product: an employee is not a user. Many staff in the businesses this was built for have no company account at all, and the employee record exists independently so they can be paid, rostered and given custody of equipment without one.
That is the right model for the operation. It also means the account-shaped tools see a fraction of the people the system holds information about.
What to do about it today
-
Write down where non-users appear in your own use
The table above is generic; yours will be shorter and specific. It is the document the process depends on, and it takes an afternoon once.
-
Search by email address, not by person
An email address is the one identifier that appears consistently across tickets, customer records and supplier contacts. It is the practical handle for a manual search.
-
Decide in advance what a request means for a ticket
A support conversation is often a record of a transaction as well as personal data, and deleting half of it leaves an agent's reply attached to nothing. Decide the policy before the first request, not during it.
-
Keep the account tooling for accounts
It works well for what it covers. The failure is expecting it to cover more, and that expectation is easy to form because the feature is named after a regulation rather than after a data structure.
What AWRA OpsHub does today
- A data export for a user account covering profile, roles, assignments, audit history and privacy state.
- Account erasure and deactivation, with the actor and the request recorded.
- Signed tracking links so an external requester can follow a ticket without being made to create an account.
- A reconciliation view of active logins that have no employee behind them.
- Audit logging that an administrator cannot delete.
What it does not do
- Any export or erasure keyed on anything other than a user account — not an email address, a customer, a supplier contact or a ticket requester.
- A cross-module search for a person by email address.
- Any retention schedule or automatic deletion of ticket correspondence.
- Any record of consent, or of the basis on which a contact detail is held.
- A register of where personal data appears across the product.
Not ours, by choice
- This page describes software behaviour and is not legal advice. What obligations you have, and to whom, is a question for somebody qualified — we are only telling you what the tool takes as input.
- The employee-is-not-a-user design is deliberate and correct for the operations this product serves. It is also the largest single source of people the account tooling cannot see, and both of those are true at once.
- Europe is here because organisations there routinely run subject-access processes as a matter of course. That is an operational fact about buyers, not a claim about any specific rule.
Two, and the first is the one that makes any process possible
Neither of these is a compliance product. They are the two data capabilities a compliance process needs underneath it.
A cross-module search by email address
One identifier, every place it appears — tickets, customers, suppliers, employees, form submissions, signatures. This is the foundation: without it, answering any question about a non-user is a person opening modules one at a time and hoping they remember all of them.
Redaction that survives the record
Removing a person's details from a ticket without destroying the transaction it documents — the agent's replies, the resolution, the timings. Deletion is easy and usually wrong; redaction is what is actually wanted and it needs designing per record type.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you have a defined subject-access process, the first item is the one to raise.
Talk to us about data subject toolingFour questions to ask any vendor about personal data
What does your export tool take as input?
A good answer sounds like
A person, ideally by email.
What it actually means
If the answer is "a user", the tool covers accounts and not people. Ours takes a user.
Can you find everywhere an email address appears?
A good answer sounds like
Yes, in one search.
What it actually means
The practical test. Without it every request is a manual sweep of every module.
Do people without accounts appear in your data?
A good answer sounds like
Yes, and here is where.
What it actually means
Every operations system holds them. A vendor who says no has not looked at their own signature or contact fields.
Is deletion or redaction offered?
A good answer sounds like
Redaction, with reasoning.
What it actually means
Deletion of a ticket destroys a transaction record. The vendors who have thought about this say redaction.
Ask what the tool takes as input
Not what it is called — what it accepts. The gap between a feature named after a regulation and a function that takes a user account is where the surprises live.
Talk about data handlingFrequently asked questions
Can I delete a ticket entirely?
Records can be removed through the ordinary deletion paths, which is a blunt answer to a precise question — it takes the transaction record with it. This is why redaction rather than deletion is what we would build, and why the policy decision is worth making before the first request rather than during it.
Does the tracking link expose anything?
It is signed, which means it cannot be guessed or altered to reach a different ticket. It is still a link in an email, so treat it as something that grants access to whoever holds it, and that is worth knowing when a shared mailbox is on the other end.
Is data residency configurable?
Where the data lives is a property of how the system is deployed rather than a switch in the product, and it is a deployment conversation rather than a feature. We would rather say that plainly than let a compliance checklist imply otherwise.
