The Copy That Leaves Without the Keys

Most software makes it easy to put data in and quietly awkward to take it out. The awkwardness is rarely written down. It shows up as an export that covers the item list but not the attachments, a support ticket that takes three weeks, or a fee that appears on the day you give notice. The test of whether your records are yours is whether you can take all of them, on a Tuesday afternoon, without asking anybody.

In AWRA that is one button, Export everything, on the My Account & Danger Zone page. It builds a single ZIP of every record and every stored file your organization owns, checksums each part, and hands it to the person who asked. This post is what is in the file, what is deliberately left out of it, who can press the button, and what happens to the copy afterwards.

There are two reasons to press it, and they are not the same. One is keeping a copy: an annual snapshot for the archive, evidence for an auditor, a backup you hold yourself rather than one you trust us to hold. The other is leaving. The export is built to serve both, and the second one is why the first one can be trusted. A provider that makes leaving easy has to keep earning the staying.

Everything means every table, not a list someone remembered

The usual way an export goes incomplete is that somebody wrote a list of what to include, and the product grew after the list was written. A module added last year, a new kind of attachment, a settings table nobody thought of as data. The export works perfectly and is missing the part you needed.

This one does not work from a list. It discovers the tables: every table in the database that carries your organization’s rows is exported, whatever it is and whenever it was added. A module that ships next month is in next month’s export without anyone touching the export. And it reads the same map that the organization-deletion purge reads, so what we would delete when you close your account and what we hand you when you leave are the same set by construction.

Files follow the same rule. Every stored file a record points at — a supplier’s quotation, a petty-cash receipt, the signature captured when a transfer was received, a supplier’s bill, a document in the vault — is copied into the ZIP and filed under the record it belongs to. Then the export walks your organization’s own storage folders and takes anything else it finds there, under a separate folder, because a file that no record points at any more is still yours.

What is in the ZIP

The CSVs are UTF-8, comma-separated, quoted where needed. An empty cell is an empty value in the database. Ids are the database’s own, so the relationships survive: an item’s category column holds the id of a row in the categories file. Dates are written as stored. A cell that held binary data rather than text is written as base64 with a prefix saying so, rather than as bytes that would break the file.

If a record points at a file that cannot be found on storage, the export does not stop and does not pretend. The file is listed in the index as missing, the count is in the README and on the page beside the export, and everything else goes out complete. An export that fails over one lost attachment is no use to anyone; one that silently skips it is worse.

The data goes out; the keys stay behind

An export is a copy of your organization that leaves the building. Anything in it that would let the holder act as your organization — sign in as one of your users, call a service you connected, receive your webhooks, charge your card — stays where it is. The rule is simple to state: what you own goes out, the keys to the workspace do not.

That is applied in three layers. Some tables are left out entirely because every row in them is a credential or a session: sign-in sessions, API tokens, password reset codes, passkeys, device push tokens, scanner and portal sign-in tokens, and internal queue and cache tables that hold no business data. Named columns in every other table are withheld: passwords, two-factor secrets and recovery codes, integration keys and secrets, incoming-webhook addresses, the private addresses that let email or a kiosk write into the workspace, and saved card authorisations. And then a safety net: any column whose name looks like a secret is withheld by default, unless it has been checked and listed as safe with the reason written beside it. A credential column added next year is held back unless someone decides otherwise, rather than shipped unless someone notices.

A withheld cell is not dropped. The column stays in the CSV and the cell reads [redacted], and the manifest lists which columns were withheld in each table. Someone reading the file in five years can see that a value existed and was deliberately kept back, rather than wondering whether the export lost it.

• Kept, because they look like secrets and are not: tax PINs, which are public identifiers printed on invoices; and the hash chain on the activity log, which is what lets the exported log be checked for edits after it has left us.
• Decrypted, because ciphertext is useless to you: employee bank account names and numbers, mobile-money numbers and statutory ids are stored encrypted. They are your data, an administrator can already read them in the app, and an encrypted copy could not be opened by any other system, so they go out readable.

The export is meant to be complete enough to leave with. That also makes it the most sensitive file your organization will ever download.

That second point is the one to plan around. The ZIP holds bank details, statutory ids, salaries, customer records and contracts in one place, unencrypted. Decide before you press the button where it is going to be stored and who will be able to open it there.

Who can press the button

The button sits behind its own permission, Export organization data, and only the Admin role gets it by default. Anyone else holds it only because somebody granted it deliberately. It is on every plan, including the free one: taking your data with you is not something we charge for.

1. Confirm with your password

   The request asks for the password again, even in a signed-in session. A laptop left open is not enough to start one.

2. One at a time

   Only one export per organization can be in progress. A second request is told the first is still being prepared. A build that stops responding for half an hour is abandoned and marked failed, so it never holds the slot for good.

3. Built in the background

   The ZIP is assembled away from your browser, a table and a file at a time. A small organization’s export is quick; a large one with years of attachments takes longer, and you can close the page.

4. Told when it is ready

   You get a notification in the bell and, unless you have switched that email off, an email. Neither carries the file or a link to it — both point to the page.

5. Downloaded by the person who asked

   On the page, a ready export has a download link minted for you when the page loads, valid for ten minutes. Anyone else following it — another administrator included — gets a not-found.

Why point the email at the page rather than the file? Because mailboxes are forwarded, shared, archived and searched. A link that works for whoever holds the email is a link to your whole organization sitting in someone’s inbox. Sending everyone through the page means the file is only ever served to a person signed in as the one who asked, with their password already checked at the request.

Seven days, then it is gone

A finished export stays on our servers for seven days and is then deleted by a nightly job; the page shows the deletion date beside each one. It is not a backup we keep for you. It is a copy for you to take, and holding a complete, decrypted copy of every organization’s data indefinitely would be exactly the kind of exposure the export is careful about everywhere else. Download it, verify it, put it somewhere you control.

Every request and every download is written to the activity log with who, when, the address it came from, the file’s size and its checksum, and each export counts its own downloads. If an export of your organization was taken, an administrator can see who took it and can match the checksum against the file they are holding. For keeping the activity log itself outside the system, see the audit trail that leaves the building.

Reading it, and loading it somewhere else

The CSVs are a faithful copy of the database, not a report. Column names are the database’s rather than the screen’s, and relationships are ids rather than names. That is what makes it complete and verifiable, and it is also why it is not in the shape of the import templates inside AWRA, which use screen labels and look things up by name. Moving the data into another system — or into a second AWRA workspace — is mapping work. We can do it for you.

One distinction worth knowing: the same page has a smaller Export your data button, for any user, that exports the data held about that one person. That is the personal request a data protection law gives an individual. The organization export is the whole workspace, and is the one this post is about.

Frequently asked questions