Skip to content
Afterglow Docs

Data retention and privacy

Afterglow supports the two GDPR data subject rights most platforms need to honour: the right of access (Article 15), delivered as a data export, and the right to erasure (Article 17), the so-called “right to be forgotten”. This page explains the principles behind how the platform handles them — what is preserved, what is deleted, and why.

Two rights, one workflow

Section titled “Two rights, one workflow”

Both rights flow through the same request system in the platform:

  • A request can be filed by the user themselves, by a coach on behalf of a client, or by an administrator.
  • Coach-filed requests are proposals that an administrator must approve.
  • Each request moves through a fixed set of statuses (Awaiting Confirmation, Pending, In Progress, Completed, Cancelled, Failed).
  • Every action is recorded in an audit log retained for at least 7 years.

For the operational guides, see Handling data export requests and Handling data erasure requests.

Why some data is retained after erasure

Section titled “Why some data is retained after erasure”

GDPR explicitly allows — and in some cases requires — controllers to retain data when another legal obligation overrides the user’s request to be forgotten. The most common case is financial record-keeping.

Under EU tax and accounting law, businesses must keep invoices, payout records, and the supporting evidence for those records for a fixed period — by default 7 years. This applies to:

  • Booking records (the evidence behind a coach’s invoices).
  • Signed user documents, such as consent forms and accepted terms.
  • The coach’s Stripe Connect account identifier, when the coach has bookings — silently kept so historic payouts can still be reconciled with Stripe records.
  • Stripe’s own records at Stripe — these are governed by Stripe’s retention policies, not the platform.

Free-text fields on these records that contain personal content (for example, the coach’s notes on a booking) are scrubbed during erasure so that what remains is the minimum necessary for compliance, not the user’s personal life.

Why the audit log captures hashed identifiers

Section titled “Why the audit log captures hashed identifiers”

When the platform processes an erasure, it cannot simply forget that the erasure happened — that would defeat the purpose of an audit trail. At the same time, the audit log must not become a back-door copy of the deleted user’s data.

The platform resolves this by storing only a one-way hash of the user’s identifier. The hash uses a peppered, versioned algorithm:

  • The original email and user ID cannot be recovered from the hash.
  • The hash is only useful for confirming that a specific known identifier was the subject of an erasure (you can hash a value and compare).
  • Versioning the algorithm lets the platform rotate it if the underlying scheme ever needs to change.

The audit log is retained for at least 7 years to satisfy regulatory expectations, and pruned automatically after that.

Tenant scope vs global scope

Section titled “Tenant scope vs global scope”

Many users belong to a single workspace, but some — particularly users at organisations with multiple Afterglow tenants — belong to several. Erasure recognises this:

  • Tenant scope removes the user’s data within one workspace only. Their account in other workspaces is untouched, and their underlying identity record remains so they can keep using those other workspaces. This is the default and the right choice for almost every request.
  • Global scope wipes the user across every workspace they belong to and removes their underlying identity record entirely. This is restricted to SystemAdmin users — the role that operates across the whole platform — and is reserved for cases where the user has the right to be forgotten everywhere.

Multi-tenant users who only want to leave one workspace should always use tenant scope. They retain access to their other workspaces.

Why the platform anonymises some content rather than hard-deleting it

Section titled “Why the platform anonymises some content rather than hard-deleting it”

Some content the user produced lives inside shared context. A chat message is part of a thread that other people remember. An article comment is part of a discussion. A moderation report is part of a record other moderators may need to review.

Hard-deleting that content would break the integrity of those threads — leaving holes that other users would notice and that auditors could not retrace.

To balance the user’s right to be forgotten against the legitimate interests of other users and the workspace, the platform anonymises these items instead of removing them:

  • The personal link is severed: the original user is replaced with a placeholder system identity.
  • Free-text content is replaced with [deleted].
  • The thread or discussion remains readable, but nothing about it is tied back to the original user.

This approach mirrors how moderation traces work on most large community platforms, and it reflects the GDPR principle that the right to erasure is balanced against the rights of others and the legitimate operation of the service.

The full set of anonymised content includes chat messages, chat requests and moderation reports, article comments and comment reports, circle membership requests and blocks, alert notifications and rules, and tenant access codes the user generated.

What is permanently deleted

Section titled “What is permanently deleted”

Personal content tied directly to the user — content that has no value to anyone else — is permanently removed during erasure. This includes:

  • Journal entries, AI analyses, emotion scores, and weekly summaries.
  • Routine activity, saved articles, completed surveys, and personal tools.
  • Research study participation — enrolments, scheduled questionnaires, and study reminders. Leaving a study mid-way (withdrawal) is a separate action that stops future questionnaires without erasing past answers; full erasure removes the study data outright.
  • Circle memberships, push notification subscriptions, and journal-related notifications.
  • The user’s profile photo and any chat attachments stored in the platform’s file storage.

External systems are also cleaned up: OneSignal user records are deleted, Stripe Connect accounts are de-authorised (unless outstanding payouts prevent it), and any pending background jobs for the user are cancelled.

For coaches, the platform’s stored Cal.com API key is wiped as part of the deletion. The coach’s Cal.com account itself is not touched — that account belongs to the coach, not the platform, and they remain in control of it after leaving Afterglow.

Section titled “Related topics”