The exit, documented by the vendor. Read it before you need it.
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.
“Give us everything”, “what do you hold about me”, “erase this person” and “close the account” are four separate requests.
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.
Reversible — nothing changes
Export the whole organization
One ZIP: every table your organization owns as a CSV, every stored attachment filed under the record it belongs to, and a manifest with each table’s columns, row count and SHA-256. Passwords, access tokens and integration keys stay behind, because a copy of them would let the holder act as you.
Who can ask
An administrator by default, re-entering their password
Effect on data
None whatsoever
Delivery
To the requester only, signed in, by an expiring link
Kept for
Seven days, then deleted from our servers
Reversible — nothing changes
Export a person's data
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.
Who can ask
Yourself, from your own account screen
Also available to
An administrator, per user, on the web and the API
Effect on data
None whatsoever
Delivery
Signed download, valid 24 hours
Irreversible for that person
Erase a person
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 record of actions, with the actor pseudonymised
One-way door
An erased user can never be restored from the recovery centre
Irreversible for everyone
Delete the organization
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.
Who can ask
Somebody permitted to delete the organization — not any administrator
Nothing to recover. There is no bin behind this one.
The part worth judging us on
Anybody can offer a delete button. The preview is where the honesty is.
Before a deletion can be scheduled, the system walks every table that holds your workspace’s records 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 thirty-seven known columns that hold a stored path, names the five storage directories that belong to the workspace, and reports the log rows.
What the preview returns
And why that specific thing
tenant_scoped_rows
The 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 | direct
Per 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_rows
The 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 thirty-seven columns that hold stored paths — document vault files, compliance evidence, report exports, workflow attachments, quotations, adjustments, payment proofs, invoices, POS receipts, supplier bills, petty cash and advance receipts, captured signatures, movement photos, profile photos and draft email attachments. It is the same list the organization export copies files from.
storage_directories[]
The actual directory paths that belong to the workspace, printed. Five of them, named, so you can see where your files live rather than being told they are "securely stored".
users / vendors
Counted separately from everything else, because they are the two figures somebody will want to sanity-check against what they believe they have.
log_rows
System 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_for
How 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
Deletion is scheduled rather than executed. That delay is the whole safety net.
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.
DAY 0Requested and confirmed
The impact preview was read, the token echoed back, the request written with a scheduled date thirty days out. The workspace keeps working normally.
DAYS 1–29Reminders, and a cancel
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.
ANY DAYCancelled, and it is over
One action ends the request. Nothing was removed, nothing needs restoring, and the workspace carries on as though it had never been asked.
DAY 30It runs
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.
Blockers refuse the whole thing
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.
Migrations block it too
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 personal data export contains
Five sections, one of which is deliberately empty — and says why.
The personal 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.
Section
Contents
profile
Name, 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.
privacy
The 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.
assignments
Roles 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.
devices
Registered devices, which is the part people are most surprised by and most entitled to see.
audit_activity
Their recorded activity: the action, the module, the route name, the HTTP method, the IP address, the user agent and the timestamp, per entry.
handover_signatures
Deliberately 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
The most important paragraph on this page is in the third column.
Specifically: the two exports answer different questions. The organization export is the portable copy of your operational data; the personal export answers one person’s privacy request. If you are evaluating lock-in, read the third column first and then read the rest.
Export & deletion — what is real
What AWRA OpsHub does today
A full export of the whole organization — every table it owns as a CSV, every stored attachment filed under the record it belongs to with an index mapping each file back to its table, record and column, and a manifest carrying each table’s columns, row count and SHA-256. Admin-only by default, password-confirmed, built in the background, delivered only to the requester through an expiring link, deleted from our servers after seven days, with every request and download audited.
Credentials withheld from that export by rule: password hashes, remember and API tokens, MFA secrets, integration keys and webhook secrets are written as [redacted], and any new column named like a secret is withheld by default until someone decides otherwise.
A per-user data export with profile, privacy state, role and place assignments, registered devices and recorded activity, generated in the background and delivered as a signed link valid 24 hours.
Self-service export from your own account screen, without an administrator in the loop.
Administrator-initiated export per user, on the web and over the API, gated on its own permission.
An explicitly excluded section that explains itself in the file — handover signatures, with the reason, where they actually live, and how to act on a request about a specific one.
Export generation recorded as privacy evidence: who asked, for whom, which sections and how many rows in each.
A privacy erasure path per user that overwrites identifying details, destroys sessions and tokens, removes role assignments and pseudonymises the actor on their audit entries — so what happened survives while who did it is no longer identifiable.
An erased user permanently barred from restore, which is the recovery centre honouring the erasure rather than quietly undoing it.
An organization deletion impact preview that counts real rows in real tables, with empty tables filtered out and each row group labelled as cascade or direct cleanup.
File references counted across thirty-seven columns holding stored paths, and the five workspace storage directories named in full.
A blocker list that refuses the whole operation — if it is non-empty no confirmation token is issued and nothing can be started.
A 15-minute confirmation token the deletion request must echo back, so a deletion cannot be requested by anything that did not just look at its impact.
A 30-day grace period with the exact scheduled date calculated, reminder emails on a gated cadence, and cancellation available throughout.
A workspace that can never appear in its own recovery centre, so a deletion cannot be reversed by the thing being deleted.
Session and token controls in the same place — sign out every other session, revoke one API token or all of them.
An honest refusal when the environment is mid-migration, rather than a deletion that half-works.
More we can add to your workspace
The organization export in the shape of another product’s import templates, rather than our own tables keyed by id, so loading it elsewhere needs no mapping step.
Scheduled recurring exports to your own storage, so a copy lands in your bucket weekly without anybody asking.
A self-service database dump or read replica, for organisations whose exit plan involves their own analytics rather than a file.
Export in an interchange format a named competitor imports directly, rather than a structured file you or an implementer maps.
A configurable grace period, so an organisation with a policy requiring ninety days can set ninety rather than thirty.
A deletion certificate, signed and dated, confirming what was removed and when — the artefact a customer's own auditor asks for.
Selective workspace deletion, removing one branch, one year or one module rather than the whole organisation.
Per-user export in a second format, such as a readable PDF alongside the structured file.
Where we point you to a specialist
We will not put credentials in an export, even your own. The organization export carries your data, not the keys to your workspace: a file that leaves the building with password hashes, tokens and integration secrets in it is a way in for whoever ends up holding it. Reconnect integrations in the next system with fresh keys.
We will not describe the personal export as a portable copy of your operational data. It answers “what do you hold about me” for one person. The organization export is the portable copy, and the two are kept on separate buttons so neither is mistaken for the other.
We will not offer an immediate, unrecoverable organization deletion. Thirty days, reminders and a cancel are not friction for its own sake — they are what stops a bad afternoon from ending a business. If your policy requires a different window, say so and we will scope it; we will not remove the window.
We will not describe a privacy erasure as though it removed the history. It removes the identity. The actions remain, with the actor pseudonymised, because an audit trail that can be emptied by an erasure request is not an audit trail — and an organisation that needed one would have lost it exactly when it mattered.
We will not restore an erased user, on request or otherwise. That is the recovery centre honouring the erasure. If somebody was erased in error, they are created again as a new person; the erased identity does not come back.
We will not tell you what your retention obligations are. The system will hold whatever period your counsel or auditor specifies, and a legal hold beats the timer. Which period is correct for your jurisdiction and your sector is not a question a vendor should answer in a sales meeting.
Scheduled exports to your own storage and an export shaped for a named product’s importer are the two items in that middle column that change an exit plan, and they are a scoping conversation about format rather than a research project. A configurable grace period and a deletion certificate are small and frequently asked for by organisations with their own retention policy. Tell us what your exit or audit requirement actually says and we will come back with a written spec, a timeline and a price.
A vendor that will not describe the exit is telling you something.
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, and the export of everything is a button rather than a promise.
A per-table row count, a file reference count and five named directories — not "your data".
A deletion cannot be fired blind
A 15-minute token from the preview must be echoed back, so nothing stale can start one.
Thirty days to change your mind
With reminder emails on a gated cadence and a cancel that leaves no trace of the request.
Erasure removes the person, not the history
Identity overwritten, actions retained with the actor pseudonymised.
A privacy request has a paper trail
Who asked, for whom, which sections, how many rows — recorded as evidence.
Everything comes out in one file
Every table as CSV and every attachment under its record, in one ZIP with a checksum for each file.
Frequently asked questions
What can I export, and in what format?
Two different things. An administrator can export the whole organization as one ZIP of CSVs and stored files — see the next answer. Separately, anyone can request a per-user data export, as structured JSON, containing five sections: profile (name, email, country, phone, photo reference, active flag, email verification, password-set time, MFA state and timestamps), the current privacy state held for that person, assignments (roles with names and descriptions, plus the warehouse, location and department as named objects), registered devices, and recorded activity with the action, module, route, method, IP address, user agent and timestamp per entry. It is generated in the background, written to secure storage, and delivered as a signed link valid for twenty-four hours.
Is that the same as exporting all of my organization's data?
No — that is the organization export, a separate button on the account and danger-zone page. The per-user export answers “what do you hold about me” for one person. The organization export is the portable copy: one ZIP with every table your organization owns as a CSV, every stored attachment filed under the record it belongs to with an index mapping it back, and a manifest listing each table’s columns, row count and SHA-256 checksum. It is admin-only by default, asks for your password, is built in the background and delivered only to the person who asked through an expiring link, and is deleted from our servers after seven days. Passwords, access tokens and integration keys are written as [redacted]. The CSVs mirror our own tables keyed by id, so loading them into another product is a mapping step we can do with you.
Why are handover signatures excluded from the export?
Because 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 a user account. It cannot be attributed to a particular user automatically, and exporting them into one person's file would disclose other people's signatures. The exclusion is stated inside the export file itself, along with where those signatures do live (on the individual stock receipt, asset movement, transfer, count session, till sale, refund or ticket, served only through that module's permission-gated route) and how to act on a request about a specific one. A privacy export that silently omits a category is worse than one that omits it loudly, because only the second can be checked.
What does erasing a user actually do?
It removes the identity and keeps the history. Name, email, phone, country, photograph, social identity and MFA secret are overwritten, the password is replaced with a random one, sessions and API tokens are destroyed, role assignments are removed, and the actor name and email recorded on that person's audit entries are replaced with pseudonyms. So what happened remains answerable while who did it is no longer identifiable. An audit trail that could be emptied by an erasure request would not be an audit trail, and an organisation relying on one would have lost it exactly when it mattered. An erased user can never be restored from the recovery centre — that is the recovery centre honouring the erasure rather than quietly undoing it.
What does the deletion impact preview show me?
Real counts, not estimates. It walks every table that holds your workspace’s records in your workspace and counts the actual rows in each, filtering out the tables holding nothing so the list you read is the list that exists, and labelling each group as cascade cleanup or direct cleanup — the distinction between rows that go with the workspace through a database relationship and rows that need removing explicitly. It separately counts file references across thirty-seven columns that hold stored paths, names the five storage directories belonging to the workspace in full, counts users and vendors separately as sanity-check figures, counts system log rows narrowly so the figure means one thing, and lists any blockers. If the blocker list is non-empty, no confirmation token is issued and the deletion cannot be started at all.
Can somebody delete our whole organization by accident?
It is made deliberately hard in three ways. First, it is limited to the Admin role: no permission can grant it to anyone else, so a manager who has been handed broad rights still cannot reach it. Second, the impact preview mints a token that lasts fifteen minutes and the deletion request must echo it back — so a deletion cannot be requested by anything that did not just look at what it would do, which rules out a stale form, a bookmarked URL or a script written against the endpoint last month. Third, the request is scheduled thirty days out rather than executed, with reminder emails and a cancel available throughout. And if the environment is mid-migration and the deletion machinery is not fully in place, the endpoint refuses with that as the stated reason rather than proceeding with an incomplete understanding of what it would remove.
How long is the grace period, and can we cancel?
Thirty days, with the exact scheduled date and time calculated rather than described, and yes — cancellable at any point during it. Cancelling ends the request entirely: nothing was removed, nothing needs restoring, and the workspace carries on as though it had never been asked. Reminder emails go out during the period on their own gated cadence, at most once a day, subject to the same notification settings as everything else so they cannot become a stream. The workspace also can never appear in its own recovery centre, specifically so a deletion cannot be reversed by the thing being deleted.
What happens after the thirty days?
A queued job removes the rows, explicitly clears the tables that need direct cleanup, and deletes the five storage directories that belong to the workspace — including any organization export still waiting to be downloaded. After that there is nothing to recover — not in the recovery centre, not anywhere. That is what the preview, the token and the grace period exist to make sure you meant.
Help Center
Need a quick answer while you read?
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
We use necessary cookies for secure sessions. With your permission, we also use cookies and browser storage for preferences, analytics, and demo engagement. Privacy Policy
AWRA OpsHub
Cookie settings
Cookie Consent Manager
Necessary cookies stay on for login, CSRF protection, and security. You can choose the optional categories below.
Overview
General Information
AWRA uses cookies and browser storage to keep public pages secure, remember selected preferences, measure website performance, and manage demo engagement prompts.
You can choose whether functional and marketing engagement storage apply. Analytics measurement is always active in this AWRA setup.
These settings apply to AWRA public website experiences such as the homepage, feature pages, pricing calculator, blog, help center, and request-demo page. Authenticated dashboard and vendor portal sessions still rely on required security cookies.
Required
Always active
Functional
Optional
Analytics
Always active
Marketing
Optional
For more context on privacy handling, open the Privacy Policy.
Required Cookies
Required Cookies
Always Active
Required cookies and storage support basic website delivery, secure sessions, request protection, and remembering the consent choice itself.
These cannot be switched off from this manager because disabling them would break login/session behavior, form protection, or the ability to remember the privacy choice you save.
Cookie details
Session security: keeps secure server sessions working while browsing AWRA.
CSRF protection: helps verify form submissions and protect requests.
Consent record: stores the preference decision so the banner does not keep asking after a choice is saved.
Examples: Laravel session cookies, CSRF tokens, and the AWRA consent preference record.
Duration: session security can expire with the browser/session; saved consent can last longer so the same browser remembers the choice.
Functional Cookies
Functional Cookies
Functional storage improves the public website experience by remembering interface choices, helper states, dismissed notices, and short-lived interaction preferences.
Turning this off does not stop secure required cookies or analytics. It only limits optional convenience memory.
If disabled, AWRA may show some helper prompts again or forget non-essential display choices. Core public pages, contact forms, and request-demo forms still work.
Cookie details
UI preferences: remembered display choices and helper states where available.
Dismissed notices: session-level or preference-level memory for notices the visitor has closed.
Frequency helpers: optional browser storage that prevents repeated prompts when allowed.
Examples: localStorage or sessionStorage values for dismissed banners, guide/helper states, and lightweight public-page preferences.
Effect when off: AWRA avoids optional convenience memory unless it is also allowed through marketing and engagement preferences.
Analytics Cookies
Analytics Cookies
Always Active
Analytics helps AWRA understand public page performance, traffic patterns, and content usefulness so we can improve the marketing website.
This category does not by itself enable demo popups, exit-intent prompts, or advertising pixels. Those are controlled by Marketing & engagement.
In this AWRA setup, Google Analytics and Google Tag Manager measurement are treated as mandatory website measurement and remain active.
Cookie details
Google Analytics / GTM: measures aggregate traffic and page activity.
Performance insight: helps identify which public pages, docs, and demo paths visitors use.
Operational signal: supports website quality decisions without enabling demo popups by itself.
Examples: Google measurement identifiers such as GA/GTM tags and related browser identifiers set by Google scripts.
Use: page views, source/referrer trends, public content performance, and product education page effectiveness.
Marketing & engagement
Marketing & engagement
Marketing and engagement storage supports demo prompts, exit-intent prompts, campaign attribution, and future advertising pixels.
When disabled, AWRA will not auto-open demo or exit-intent popups. CTA buttons can still open a form because that is a direct visitor action.
When enabled, AWRA can remember that a visitor already saw, dismissed, or submitted a demo prompt so the same popup is not repeated aggressively.
Cookie details
Demo prompt memory: tracks whether an auto prompt or exit prompt was recently dismissed.
Demo submission memory: avoids asking again after a visitor submits a demo request.
Campaign context: keeps source page, referrer, and UTM context available for demo requests.
Examples: popup frequency caps, demo-submitted flags, engagement source fields, and UTM/referrer context.
Effect when off: auto demo prompts and exit-intent prompts stay blocked; normal navigation and manually clicked CTA buttons still work.
