Appearance
Anonymising a contact
Somebody asks you to erase their data. Anonymise on their contact does it: their name, contact details and personal information are removed, while the invoices, payments and attendance they are part of stay — with nothing left on them that says who they were.
It cannot be undone
Anonymising is permanent. There is no restore, and no copy of the removed details is kept anywhere in Xperios. The seven-day wait described below is your only opportunity to change your mind.
Who can do it
Administrators only, and only on an archived contact. The Anonymise… button is on the toolbar and appears for an administrator looking at an archived person — never an organisation, and never somebody already anonymised. The permission is checked again when the request is made, so the button being there is not the only thing standing between a mistake and the data.
Archive them first
If Anonymise… is not on the toolbar of somebody who ought to qualify, the usual reason is that they are not archived yet. Archiving is the reversible step and comes first; anonymising is the irreversible one and comes after.
Asking for it
- Archive the contact, if they are not archived already.
- Click Anonymise….
- The dialog explains what will happen. Type their name to turn on Anonymise in 7 days, then click it. Cancel closes the dialog and records nothing.
- A banner then sits on the contact: Requested by {who} on {date}: they will be anonymised on {date}. The toolbar button becomes Cancel Anonymise.
Nothing is removed at this point. A job each day anonymises the people whose seven days have passed.
Stopping it
Cancel Anonymise on the contact, and confirm. The request is withdrawn and recorded as cancelled, and the person is left exactly as they were.
Unlike asking, cancelling does not depend on the contact being archived: once a request is waiting, the button to stop it is there whatever state the record is in.
This is why the seven days exist. Once they pass and the job runs, nothing can be recovered — so if there is any doubt about whether the request was properly made, cancel it and ask again rather than letting it run.
When Xperios will not do it
The dialog tells you which of these is in the way, and records nothing:
Not archived
- Not archived - archive the contact first. Checked on the server as well as by the toolbar, so this is the answer whichever route you came by.
Never, whatever you do
- an organisation, rather than a person
- a staff user
- somebody already anonymised
Because something is unfinished
- money owed, or a balance in credit
- a payment schedule that is active or on hold
- equipment not returned
- current or waiting tuition, group membership or hire — as the pupil or as the payer
- a current teacher
- linked to an organisation that is not archived: remove the link first
These are the same holds the weekly archive and anonymise run uses. They exist because anonymising somebody who still owes you money, or still has your clarinet, loses you the only record of who to ask.
Parents and children
A parent of a pupil who has not been anonymised cannot be anonymised — their details are how the child's records make sense.
A whole family can still be dealt with together: a parent may be requested once each of their children has either been anonymised already or has a request of their own. On the day, the children are anonymised first and the parent after.
On the day
Every check runs again before anything is removed. If something has changed since the request — new tuition, a new balance — the request is held back rather than carried out. The banner then reads held back: {reason}, and the job tries again each day until the reason clears or somebody cancels.
So a request is not a promise that it will happen on that date. It is a promise that it will not happen before it.
Restoring somebody does not cancel their request
Bring a contact back out of the archive while a request is waiting and the request is held back, not abandoned: held back: Restored from the archive - archive them again, or cancel the request. It then waits, and is tried again each day.
So restoring somebody buys time rather than settling it. Archive them again and the request goes ahead on the next run; Cancel Anonymise is what actually withdraws it.
What is removed, and what is not
Removed: the person's name (it becomes (Anonymised)), their contact details and their personal information, across their contact, pupil, debtor, teacher and user records, their associations, and the hire, group, tuition, schedule, invoice and equipment rows that named them. They stop appearing in contact searches, including when archived contacts are shown.
Kept: the money and the history. Invoices, payments, schedules and attendance remain, so your accounts and your returns still add up — they simply no longer say who.
Four things anonymising does not reach
Not cleared by this, nor by the weekly run:
- the text of messages sent to or from them
- journal entries
- answers they gave on an application form
- documents stored against them
Any of those can still carry a name, an address or a phone number in free text. If you are answering an erasure request, deal with those separately — the anonymising will not do it for you.
Where it is recorded
Everything appears in the Archive and Anonymise log — the Master query Contacts - Archive and Anonymise Log: requests as Requested with their due date, withdrawals as Cancelled, and completed ones as done, naming who asked and when it happened.
The Archive / Anonymise Pending dashboard tile has a Requested line, and its On Notice headline counts requests alongside the people the weekly run has found.
How this differs from the weekly run
| Anonymise on a contact | Archive and Anonymise settings | |
|---|---|---|
| Who it covers | One person you choose | Anyone whose family has been inactive for the years you set |
| What starts it | An administrator asking | The weekly job |
| Depends on the settings | No | Yes — the years, and Process Automatically |
| Wait before it happens | 7 days | 7 days on the report |
| What it then does | Identical — both use the same procedure | Identical |
A request does not need Process Automatically switched on, and does not care what the years-inactive settings say. It is an administrator's own decision about one person, which is exactly what an erasure request is.