Nobody asks about leaving during a sales conversation, and everybody wishes they had eighteen months later. So here it is in advance: what you can export, what deletion actually removes, how many rows and which storage directories, how long you have to change your mind, and where we say plainly that a thing is not what you might hope it is.
Three different things
They arrive in the same conversation and they have almost nothing in common. Conflating them is how an organisation accidentally erases an employee when it meant to export their file, or closes a workspace when it meant to remove one person's personal data. Each has its own route, its own permission and its own consequences.
A structured JSON file describing one user: their profile, their assignments, their registered devices and their recorded activity. Generated in the background and delivered as a signed link that expires.
A privacy erasure. Identifying details are overwritten, sessions and tokens destroyed, role assignments removed, and the actor name and email on their audit entries replaced — so the history of what happened survives while the person is no longer identifiable in it.
The whole workspace: every record, every file, every user. Preceded by an impact preview, gated on a short-lived token you have to echo back, then scheduled with a thirty-day grace period and reminder emails before anything is removed.
The part worth judging us on
Before a deletion can be scheduled, the system walks the tenant-scoped tables in your workspace and counts the actual rows. Not an estimate, not a summary — a per-table count, with the tables holding nothing filtered out so the list you read is the list that exists. It separately counts file references across nineteen known columns that hold a stored path, names the four storage directories that belong to the workspace, and reports the log rows.
tenant_scoped_rowsThe total across every table carrying your workspace identifier. It is the number that makes the decision real — "147,882 rows" lands in a way "your data" does not.
tables[]A per-table breakdown, with the tables holding nothing removed. Reading it is how you notice the module you forgot you were using.
cleanup: cascade | directPer table, whether the rows go with the workspace through a database relationship or need removing explicitly. That distinction is the difference between a deletion that finishes and one that leaves orphans, and it is published rather than assumed.
non_fk_leftover_rowsThe count that need direct cleanup, called out as its own figure. This is us telling you which part of the job is the fiddly part.
files[]File references counted across nineteen columns that hold stored paths — document vault files, compliance evidence, report exports, workflow attachments, quotations, adjustments, payment proofs, invoices, POS receipts, profile photos and draft email attachments.
storage_directories[]The actual directory paths that belong to the workspace, printed. Four of them, named, so you can see where your files live rather than being told they are "securely stored".
users / vendorsCounted separately from everything else, because they are the two figures somebody will want to sanity-check against what they believe they have.
log_rowsSystem log rows, counted separately and deliberately narrowly — only the system log, not every table that happens to have "log" in its name, so the figure means one thing.
blockers[]Reasons the deletion cannot be scheduled at all. If this list is non-empty, no token is issued and nothing can be started. A refusal you can read beats a failure you cannot.
grace_days / scheduled_forHow long you would have, and the exact date and time it would run, calculated rather than described.
And a detail that says more about the design than any of the above. The preview mints a short-lived token — fifteen minutes — and the deletion request has to echo it back. Which means a deletion cannot be requested by anything that did not just look at the impact of it. Not a stale form, not a bookmarked URL, not a script somebody wrote last month against the endpoint. You saw what it would do, in this session, minutes ago.
Thirty days
An immediate delete is a feature that eventually destroys somebody's business over a bad afternoon. A scheduled one with a grace period, reminder emails and a visible cancel is the same capability with the consequence of a mistake removed.
The impact preview was read, the token echoed back, the request written with a scheduled date thirty days out. The workspace keeps working normally.
A reminder email goes out on its own cadence — at most once a day, gated by the same notification settings as everything else, so it cannot become a stream. The request is visible and cancellable throughout.
One action ends the request. Nothing was removed, nothing needs restoring, and the workspace carries on as though it had never been asked.
The queued job removes the rows, clears the directly-cleaned tables and deletes the storage directories. After this point there is nothing to recover — not in the recovery centre, not anywhere.
If the workspace is in a state that cannot be safely deleted, the preview returns a blocker and no confirmation token is issued — so the request cannot be started at all rather than starting and failing halfway. And the same rule appears one layer down: a workspace can never appear in its own recovery centre, precisely so that a deletion cannot be reversed by the workspace that is being deleted.
If the deletion-request machinery is not fully in place — a partly-migrated environment, mid-upgrade — the endpoint refuses with that as the stated reason rather than proceeding with an incomplete understanding of what would be removed. An honest “not right now” is better than a deletion that half-works.
What a data export contains
The export is a per-user file answering “what do you hold about me”. It is generated in the background, written to secure storage, and delivered as a signed link valid for twenty-four hours, so the file is never sitting behind a guessable URL.
profileName, email, country, phone, photo reference, active flag, when the email was verified, when a password was last set, whether MFA is enabled, and the created, updated and deleted timestamps.
privacyThe current privacy state held for this person, so the export answers what your consent and preference records say as well as what your user record says.
assignmentsRoles with their names and descriptions, and the warehouse, location and department the person is attached to — each as a named object rather than an identifier you would have to look up.
devicesRegistered devices, which is the part people are most surprised by and most entitled to see.
audit_activityTheir recorded activity: the action, the module, the route name, the HTTP method, the IP address, the user agent and the timestamp, per entry.
handover_signaturesDeliberately EXCLUDED, with the reason stated in the file itself: a captured signature identifies the person who signed — usually a customer, driver or custodian rather than a system user — and is stored against the movement rather than against an account. It cannot be attributed to this user automatically, and exporting them here would disclose other people's signatures. The file names where they do live and how to act on a request about a specific one.
That last row is the most useful thing on this page. A section that could plausibly have been included, was not, and explains itself inside the file — including where the data does live and what to do if a request genuinely concerns it. A privacy export that silently omits a category is worse than one that omits it loudly, because only the second one can be checked.
Generating an export is itself recorded as privacy evidence: who asked, for whom, which sections were produced and how many rows were in each. So “we responded to that request” is a record rather than a recollection.
The straight answer
Specifically: this is a privacy export, not a portable copy of your operational data. If you are evaluating lock-in, read that first and then read the rest.
Nearby
The same discipline at record level: what a soft delete is, why a permanent one gets refused, and legal holds.
OpenWhere data is held, who processes it, and the current position on each compliance question.
OpenThe honest state of each certification and control claim, rather than a wall of badges.
OpenWhy an erasure pseudonymises the actor rather than removing the entry, and how ordering is shown to be intact.
OpenThe third parties involved, published, so an exit conversation includes them.
OpenThe practical export path today — module data in PDF, CSV and XLSX, on a timer if you want it.
OpenWhy we publish this
You are choosing a system you may run for a decade. The question is not whether leaving is easy — it is whether the answer was written down before you needed it, and whether the awkward parts are in it. Ours are in the third column above, including the one about the operational export.
A per-table row count, a file reference count and four named directories — not "your data".
A 15-minute token from the preview must be echoed back, so nothing stale can start one.
With reminder emails on a gated cadence and a cancel that leaves no trace of the request.
Identity overwritten, actions retained with the actor pseudonymised.
Who asked, for whom, which sections, how many rows — recorded as evidence.
A whole-workspace portable archive does not exist yet, and this page says so.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
