Data Retention
PurpletGo lets you set one retention policy per organization for completed offboarding records, and gives you a workflow for handling right-to-erasure requests on top of it. Both live under Settings → Data Retention and require the Super Admin, Admin, or HR role (Admin/Super Admin to change the policy itself).
Data Retention is available from the Team plan up.
How the retention policy works
There's a single policy per organization, not one per offboarding type. It has four parts:
- Retention period - how many days after an offboarding is marked
completedbefore it's eligible for purge (minimum 30 days) - Action - either
anonymizeordelete - Enabled - whether the automated nightly sweep actually runs for your org
- Notify before - how many days ahead of the purge date to warn admins (minimum 1 day)
Every night, PurpletGo scans for offboardings that are completed, past their retention window (measured from exit_date, or from the last update if no exit date was set), not already anonymized, and not under legal hold - and applies the configured action to each one.
If your policy's action is set to delete, matching offboarding records are deleted outright, not anonymized. Choose anonymize if you want to keep the record for aggregate reporting.
Anonymize replaces personally identifying fields with [Redacted] (or nulls them out) across the offboarding record, the linked employee record, uploaded compliance documents, exit interview responses, offboarding notes, portal interaction logs, the alumni profile, knowledge-transfer items, and shipment recipient details. It also revokes any outstanding self-service portal link for that offboarding so it can't be used to view data that was just anonymized.
There's also a Run Now action for admins who want to apply the current policy immediately instead of waiting for the nightly job.
Legal holds
A legal hold is a boolean flag on an individual offboarding record, toggled by an Admin or Super Admin (with an optional reason) from that record. Records under legal hold are skipped by both the automated sweep and manual Run Now runs, regardless of how long they've been completed.
Erasure requests
To handle a right-to-erasure request:
Log the request
Go to Settings → Data Retention → Erasure Requests and create a new request with the individual's name, email, and (optionally) the requester's name and email and a reason. You can link it to a specific offboarding record if one exists.
Approve or reject
An Admin, Super Admin, or HR user reviews the request and marks it approved or rejected. Rejecting requires no further action; a rejection reason can be recorded.
Execute
Once approved, a separate Execute action actually runs the erasure - it performs the same anonymization described above against the linked offboarding record. Executing also scrubs the personal data captured on the erasure request record itself (the requester's and subject's name and email), so the erasure log doesn't end up holding a second copy of the data it was meant to remove.
An erasure request can only be executed once - trying again returns an error rather than silently no-oping.
Exporting an individual's data
From an offboarding record, Export Data Package downloads a single JSON file containing that offboarding's core fields, checklist items, compliance documents, matching audit log entries, exit interview responses, and portal interaction history. It's one JSON file, not a ZIP - there's no bundled HTML summary.