Handling data erasure requests

A data erasure removes a user’s account and personal data from the workspace. This page walks through how to confirm an erasure, when you may skip the 30-day grace window, what is preserved for legal reasons, and how to handle a failed run.

How a request reaches you

An erasure request can arrive from three places:

The user filed it themselves from the mobile app or /account/privacy. The 30-day grace window starts immediately.
A coach filed it on behalf of a client. It lands as Awaiting Confirmation and waits for your approval.
An admin (you or a colleague) filed it directly from the Privacy & Compliance area.

You take action when a request is Awaiting Confirmation, when you are filing one yourself, or when a request has Failed.

Step 1 — Open the request

Open Privacy & Compliance from the sidebar and click Requests.
Filter by type Erasure.
Click the request you want to review.

The detail page shows the target user, who filed the request, the reason given, and the current status.

Step 2 — Run the confirmation dialog

When you click Confirm Erasure (or Approve on a coach proposal), a confirmation dialog opens. It is intentionally strict — you cannot dismiss it with a single click.

Erasure confirmation dialog with type-to-confirm field and skip-grace toggle

The dialog asks you to:

Re-read the target user’s email and registration date. They are shown again at the top of the dialog.
Provide a reason. This is mandatory. Common values are “User request via support email”, “Coach proposal — client off-boarding”, or a court order reference. The reason is stored in the audit log.
Type the user’s email into the confirmation field. The Confirm button stays disabled until the email matches exactly. This guards against accidental erasure of the wrong user.
Decide whether to skip the 30-day grace window — see the next section.

The “Skip 30-day grace period” toggle

By default, the toggle is off and erasure follows the normal flow: the user has 30 days to cancel before the platform actually deletes anything.

You may switch it on only when there is a strong, documented reason that justifies bypassing the grace window. Acceptable reasons are:

A court order instructing immediate erasure.
A confirmed account compromise where waiting risks further harm.
A written waiver from the user explicitly asking for immediate deletion.

Do not skip the grace window for ordinary “the user is in a hurry” requests. The grace period is the user’s safety net against mistaken or coerced requests, and removing it is a serious decision. Whatever you choose, the audit log records both the toggle state and the reason you provided.

Step 3 — Watch the inline guards

If the target user falls into one of two pre-flight states, the confirm button stays disabled and the dialog shows you why:

Sole tenant administrator — The user is the only Admin in the workspace. Promote another user to Admin first via User Management, then return to the request.
Active future bookings — The user is a coach with bookings still in the future. Cancel those bookings (or have the coach cancel them) before approving. Hard-deleting a coach with live bookings would leave their clients without a session.

These guards exist to prevent the platform from deleting a user whose absence would break workspace operations or another user’s experience.

Step 4 — What happens after you confirm

If the grace window applies:

The request moves to Awaiting Grace Period.
The user receives a confirmation email and a 1-day-before reminder near the end of the window. Coaches who file an erasure for themselves see a countdown card on their /account/privacy page.
The user (or anyone with permission to act on their behalf) can cancel any time during the 30 days. Cancellation moves the request to Cancelled and nothing is deleted.
After 30 days the platform automatically begins the actual deletion.

If you skipped the grace window, the platform begins deletion immediately.

The request goes to In Progress, then Completed when finished. The user (if their notification channels still exist) and the admin who approved the request receive a completion notification.

What gets deleted, retained, and anonymised

Erasure does not mean every database row is removed. The platform applies three different treatments depending on legal obligations and platform integrity.

Deleted

Personal content tied directly to the user is permanently removed. This includes:

Journal entries, AI analyses, emotion scores, and weekly summaries.
Routine activity, saved articles, completed surveys, and personal tools.
Research study participation — the user’s enrolments, scheduled questionnaires, and study reminders.
Circle memberships, chat threads they own, journal-related notifications.
Profile photo and any attachments they uploaded.
Push notification subscriptions on OneSignal.

Retained (for legal reasons)

Some records must be kept to comply with EU tax and accounting law, which requires invoices and payout records to be preserved (default 7 years). These records remain after erasure:

Booking records, with the client’s free-text notes scrubbed to remove personal content.
Signed user documents (consent forms, terms acceptance) — the signature record remains.
The coach’s Stripe Connect account ID, if the user is a coach with bookings. This is silently retained so historic payouts remain reconcilable.
Stripe’s own records at Stripe — the platform does not control these.

Anonymised

Some content sits inside shared community context. Hard-deleting it would break the integrity of conversations and audit trails for other users. These items are kept but the personal link is severed: the original user is replaced with a placeholder, and free text is replaced with [deleted]. This includes:

Chat messages, chat requests, and chat moderation reports.
Article comments and comment reports.
Circle membership requests and circle blocks.
Alert notifications, alert rules, and tenant access codes the user generated.

The audit log keeps only a one-way hashed identifier of the deleted user — there is no way to reconstruct the original email or user ID from it. The audit log itself is retained for at least 7 years and then automatically pruned.

For the legal background behind this split, see Data retention and privacy.

What to do if a request fails

A request can reach the Failed status if an external system refuses or times out. The most common cause is Stripe: if the coach has outstanding payouts that have not yet settled, Stripe will refuse to de-authorise the connected account, and the orchestrator marks the request as Failed rather than continuing with a half-finished erasure.

When this happens:

Open the failed request and read the failure reason in the timeline.
If the reason is outstanding payouts, wait until Stripe has settled them (usually within a few business days) and file a fresh erasure request.
If the reason is a transient external error, retry by filing a fresh erasure.
If the reason is unclear, contact your Afterglow representative with the request ID.

Failed requests are not retried automatically — the platform deliberately stops so that an admin can decide what to do next.

Tenant scope vs global scope

Two scopes are available:

Tenant scope (the default in this area) deletes the user’s data in this workspace only. If the user belongs to other workspaces, their account in those workspaces is untouched and their underlying identity record remains. Use this for everyday requests.
Global scope wipes the user across every workspace they belong to and removes their underlying identity record entirely. Only SystemAdmin users can run a global erasure, and it is reserved for cases where the user has the right to be forgotten across the entire platform.

When in doubt, use tenant scope. A user can always file a separate erasure for each workspace they are part of.