Exporting Your Organization’s Data

The full export is a single ZIP holding every record and every stored file in your organization. It needs the Export organization data permission, which reaches the Admin role by default and anyone else only when an administrator grants it deliberately. It is available on every plan: taking your data with you is not a premium feature. Open Settings, My Account & Danger Zone, scroll to Export everything in this organization, enter your password under Confirm with your password, and click Export everything. Only one export of an organization is prepared at a time; asking again while one is running tells you it is already being prepared.

The export is built in the background, so you can keep working or sign out. Large organizations can take a while. When it is ready you receive a notification in the bell and an email, both pointing at the same page rather than at the file itself. The row on the page then reads Ready with the size, the number of tables, rows and files, and the date it will be deleted, plus a Download button. If some files a record refers to were not found on storage, the row says how many and lists them in the index inside the ZIP.

Only the person who asked can download, and only while signed in: the Download button is a signed link valid for a few minutes, issued again each time the page is opened, and anyone else following it is refused even with the same permission. The ZIP is deleted from AWRA’s servers seven days after it was generated, after which the row reads Expired and deleted. Requesting and downloading are both written to your audit log. The separate Export your data panel on the same page, with its Request data export button, is a different thing: a copy of your own account’s data, not the organization’s.

Start with README.txt: it names your organization, when the export was generated and the totals. manifest.json lists every table with its CSV path, row count, column names and types, the column that tied each row to your organization, which columns were withheld, and a SHA-256 checksum of the CSV. The data folder holds one CSV per database table, named after the table, so items.csv, vendors.csv, journal_entries.csv and so on, and one of them holds your organization’s own profile row. Every table that carries your organization’s rows is included, because the export reads the same list the deletion process uses.

Stored files sit under files, arranged by table, record id and column — for example the receipt attached to expense 412 sits in a folder for expenses, record 412, and the column that held it. files/index.csv maps every file back to its table, record and column, with its size and checksum, and files/unreferenced holds files found in your organization’s storage that no record points at any more. The CSVs are UTF-8 with a header row; the column names are the database’s, not the screen labels; an empty cell means no value; dates are as stored; and relationships use ids, so items.category_id points at a row in categories.csv.

In practice: an auditor asks for every supplier bill of the year with its scanned original. The finance lead opens supplier_bills.csv, filters by bill date, and uses files/index.csv to find each bill’s attachment by record id. Before sending the folder on, she checks the CSV’s checksum against manifest.json so the auditor can do the same on arrival. One thing to know before reusing the data: the CSVs are a faithful copy of the tables, not the shape of AWRA’s import templates, which use screen labels and names rather than ids, so moving data into another workspace is mapping work — and AWRA can do that mapping for you.

An export is a copy of your organization leaving the building, so anything that would let its holder act as your organization stays behind. Password hashes, remember-me and API tokens, two-factor secrets and recovery codes, integration keys and secrets, incoming-webhook URLs, inbound email address tokens, kiosk links and saved card authorisations are written as [redacted], keeping the column so a reader can see something was deliberately withheld. Some tables are left out completely because every row is a credential or a session — sign-in sessions, access tokens, password resets, passkeys, device push tokens and the job queues. Any column whose name looks like a secret is withheld by default unless it is known to be safe.

Employee bank details and statutory ids are stored encrypted in AWRA, and they are decrypted into the export: they are your organization’s data and would be useless to another system as ciphertext. That makes the ZIP sensitive. Keep it somewhere access-controlled, do not email it around, and delete working copies when the job is done. Cells are written exactly as stored, so a spreadsheet may treat a cell beginning with =, +, - or @ as a formula; when opening text that came from outside your organization, open it as text.

Use the full export when you need everything at once and in your own hands: a year-end archive kept outside any vendor, evidence for an external audit or a donor’s data request, a data-protection review of what you actually hold, or leaving AWRA. For one list — this month’s stock, a vendor register — the export buttons on each screen are faster and arrive in screen labels. In practice: an NGO closing a grant takes a full export on the last day of the grant period, checks the checksums, stores the ZIP in its records system with the grant file, and has a complete, verifiable record that does not depend on any login.