Changelog

All notable changes to the PurpletGo platform and public API are recorded here. PurpletGo follows Semantic Versioning (opens in a new tab) for the public REST API.

Unreleased

• Check an audit log export yourself - CSV and JSON exports download as a ZIP with the file, its signature, verification.json and PurpletGo's public key. Chain anchors are signed and listed at GET /api/audit-log/anchors, and server/scripts/verifyAuditExport.js checks a bundle with Node.js alone. See Audit Log.
• Every audit event goes to your SIEM - in real time, as each entry is written. Choose all events or a list per target, and JSON or CEF for Splunk and generic targets. Deliveries are queued and retried for at least 68 hours; a target shows its last error and the deliveries given up on. Batch export queues 10,000 entries at a time and continues with a cursor. See SIEM Integration.
• Archive retention - each audit archive holds only the entries since the previous one and is deleted after your organization's archive retention period (7 years by default, at least 365 days), unless a case is under legal hold. See Audit Log: archives.

Changed

• Webhook deliveries are retried for longer and logged - a delivery that fails is now tried again 1 minute, 5 minutes, 30 minutes, 2 hours, 8 hours and 24 hours later (7 attempts, instead of 4 within 7 seconds), and is recorded before it is sent, so a restart no longer loses one. Each endpoint under Settings → Webhooks has a delivery log with the status, attempts, last HTTP status and error of every delivery, and Redeliver for one that failed (also GET /api/v1/webhooks/:id/deliveries and POST .../redeliver, with the webhooks:read and webhooks:write scopes). An endpoint now shows when it last received a delivery and its failures in the last 24 hours, and is paused automatically after 25 deliveries in a row are given up on, with Super Admins and Admins told in the app and by email. The X-PurpletGo-Delivery ID is still the same on every attempt. See Webhooks: retry policy.
• Dates follow your organisation's time zone (Settings → General → Time zone). Whether a last day, task, asset return or document is due, overdue or expired, day-based automation rules, contract end dates and approval delegations now use the day as it is in your time zone, not UTC. Report months, quarters and years run midnight to midnight there too; reports before this release counted them in UTC, so a month can differ slightly from an earlier export. Timestamps are still stored in UTC.
• Portal codes go by text when SMS is set up - when your plan includes SMS, Twilio is connected and a personal mobile is on file, the one-time code that opens the self-service portal goes by text, and by email only if the text can't be sent. The link itself only ever goes by email: the text that used to carry it now says the link was emailed. Getting in then takes both the personal mailbox and the phone. Without SMS, the code goes by email as before.
• Portal sessions time out - a portal session ends after 30 minutes without activity or 12 hours after the code was entered, whichever comes first, and the employee enters a new code. Only the employee's own actions keep a session open: the chat refreshing in the background, or HR's messages being marked read, don't.
• Revocation failures say why - a failed app now shows the vendor's HTTP status and reason, for example Okta revocation failed (HTTP 403): Insufficient permissions; a timeout or connection failure says so. Errors inside PurpletGo still show no detail. The reason is cleaned of anything that looks like a secret and cut to 300 characters; the vendor's raw response is never stored or sent. The status also goes to SIEM and webhooks as vendorStatus.
• A time limit on every vendor call - each call to a vendor during revocation now gives up after 30 seconds (legal-hold archive downloads get longer), so one vendor that doesn't answer can't hold up the rest.
• Revocation runs in the background - Revoke all access starts the revocation and the dialog shows each app's result as it finishes. You can close the dialog and the run carries on; open it again to follow it, and the offboarding's page shows Running: 2 of 5 apps meanwhile. An offboarding has one revocation at a time: starting another while one is going shows the one already running.
• A time limit on each revocation run - a run starts no new app after 8 minutes and stops vendor calls still going at 10 minutes. Apps it didn't reach show Not attempted and still have access; Try again finishes them, skipping apps already revoked. A run cut short by a server restart shows as stopped, with the apps it finished.
• Google Workspace is read back in full - after revoking, PurpletGo checks that the account is suspended, with no third-party app tokens and no group memberships left. Anything left makes the result Failed with "NOT CONFIRMED" and what is left, for example 2 groups left. When the account is read again about a day later, being back in a group now also makes the result Failed and tells Admins (groups aren't checked on a case under legal hold).
• The Microsoft 365 auto-reply names the manager - colleagues who email the person are told to contact the manager's email on the offboarding; without one, the reply still says "Please contact your manager". The auto-reply is on by default and can now be turned off in Integrations → Microsoft 365 / Azure AD → Settings (recorded in the audit log).
• "The employee's manager" in automation emails - uses the manager's email on the offboarding first. A manager recorded in the employee directory as an email address (as BambooHR does) is now used as it is.
• Erasure reaches the audit log - personal details in audit log entries (names, email addresses, phone numbers, employee IDs, home addresses, IP addresses, browser details, notes and reasons) are now encrypted with a key for the person's records. Executing an erasure, or a retention run that anonymizes or deletes a record, destroys the key in the same step: every entry stays and the hash chain still verifies, but those details read [erased] everywhere, including exports downloaded later and the archived copies. Copies already sent to SIEM, webhooks or email, and exports downloaded before, are not reached. Nothing is erased while a legal hold is on. PurpletGo support sees [personal data] in their place. See Data Retention: the audit log.
• Searching the audit log by name finds entries through the person's current offboarding and directory records; an erased person can no longer be found by name.
• Retention delete anonymizes first - records that outlive the deleted offboarding (alumni profiles, references, background checks, the original offboarding request, compliance evidence and notes on the replacement hire's onboarding) no longer keep the person's data.
• Erasure covers more - it also deletes in-app notifications about the person, scrubs their other erasure requests, bulk offboarding results, onboarding notes, revocation run messages and Google Drive transfer errors, and clears the reason on the executed request.

New

• Require two-factor authentication, on every plan - a Super Admin can make two-factor sign-in mandatory for members who sign in with a password or Google (Settings → Security). Each member gets a grace period to set it up (none, 3, 7, 14 or 30 days; 7 by default), with a reminder; after it, they can only open their profile until they do. Single sign-on users are not affected. Off until a Super Admin turns it on, and every change is in the audit log. Turning it off asks for the Super Admin's password again and tells the other Super Admins in PurpletGo and by email.
• A time zone for one offboarding - for someone who works somewhere other than your organisation's time zone, set theirs in the wizard or when editing the offboarding (and timezone in the public API). Their last day then ends at midnight there, which is when access is revoked automatically, and their reminders, overdue tasks and automation days follow that calendar. Leave it empty to use the organisation's. Report months stay on the organisation's time zone.
• Every documented webhook event is sent - offboarding.deleted, asset.returned, checklist.completed and document.signed were listed but never sent; they are now, and offboarding.created now goes out for every new offboarding, including bulk offboarding, CSV import and HRIS sync. New: revocation.completed after every revocation run and revocation.failed when an app failed or needs removing by hand, both with each app's result, and asset.overdue, once per return deadline. Each endpoint gets one delivery per event, under the most specific name it subscribes to. See Webhooks for the data each event carries.
• SIEM revocation_failed - a high-severity event sent alongside access_revoked when any app in a revocation run failed or needs removing by hand.
• Overdue asset email - admins get one email a night listing the assets that have just passed their return deadline.
• A manager's email on each offboarding - optional, filled in from the employee directory in the wizard when it knows the manager, and editable when editing the offboarding. It can't be the person's own address. The Microsoft 365 auto-reply, Google Drive transfer and automation emails to the manager use it.
• Google Drive transfer to the manager - off by default; a Super Admin turns it on in Integrations → Google Workspace → Settings. Once the person's access is removed and confirmed, their Drive files, shared and private, are transferred to the manager's email on the offboarding. A connection made before this release must be reconnected once to grant the Drive transfer permission (the Google Workspace card warns while it is missing), and the manager must be a user in the same Google Workspace. Under legal hold the transfer waits until the hold ends. The offboarding's page shows its progress, checked every hour. A failed transfer doesn't change the revocation result: Admins are notified, and it is finished in the Google Admin console. See Integrations: Google Workspace.

Improved

• Automatic revocations no longer wait for each other - when last days end, each offboarding is revoked on its own, several at a time, so one slow vendor no longer delays everyone else's. A run that doesn't finish, including one stopped by its time limit or a server restart, is tried again 15 minutes later and then an hour later, 3 attempts in all, and after the third HR, Admins and whoever started the offboarding are told. A run still going after 20 minutes is flagged on the record.
• Changing the last day starts the retries over - while the automatic revocation is still waiting to run or to be retried, a new last day gets all 3 attempts.
• Revoking after the last day counts - once the last day has ended, a revocation started from the dashboard that covers every listed app, with each one revoked, counts as the automatic one and clears a Failed automatic revocation.
• AWS IAM Identity Center application assignments - revocation also removes the person's application assignments (Amazon Q, QuickSight, SAML applications and others), with their group memberships and account assignments, and reads all three back. The user is never deleted.
• Identity Center under legal hold - on a held offboarding, application assignments are kept and the result is By hand, naming them: leaving an application can make it delete what the person holds there. Group memberships and account assignments are still removed. Remove the application assignments after Legal releases the hold, then mark them as removed.
• Identity Center permission check - the AWS settings check whether the two new permissions are there when you save Identity Center, and again with Check permissions, and show a banner naming any that is missing. To test the delete permission, PurpletGo asks AWS to remove an application assignment that cannot exist; it appears in your CloudTrail as a failed DeleteApplicationAssignment call, and the check is recorded in your audit log. It names a permission as missing only when AWS refuses it by name; any other answer shows as "could not check", with AWS's reason. If Identity Center runs in another account than the credentials (for example a delegated administrator), enter that account's ID in the same settings. The check needs the two actions allowed on "Resource": "*"; if your policy allows them only on named applications, choose Our policy is scoped: skip this check (recorded in your audit log).
• Google Workspace under legal hold - on a held offboarding, the account is still suspended, signed out and its third-party tokens revoked, but its group memberships are now kept, as on Microsoft 365, and the result still counts as revoked. A Drive transfer to the manager waits until the hold ends.
• AWS under legal hold - for a person whose offboarding is under legal hold, AWS access is stopped without deleting anything: access keys, SSH public keys, signing certificates and service-specific credentials are deactivated and kept, and a DenyAll policy blocks every action. This needs the four permissions above; without one, that credential type is reported as By hand on a held case.
• AWS credentials - revocation also removes SSH public keys, signing certificates and service-specific credentials. A type the policy cannot list or remove is reported as By hand, naming what to remove.
• Webhook retries can be told apart - X-PurpletGo-Delivery stays the same on every retry of one delivery, so your receiver can drop duplicates, and the test ping sends it too. Webhook and SIEM deliveries make up to 4 attempts, 1, 2 and 4 seconds apart.
• "All checklist items complete" automation rules run once, when the last open task is closed, including when it's closed by its linked record or a resolved IT ticket. Editing a task that's already done no longer runs them again.
• Marking HR's messages read in the self-service portal is now recorded in the audit log, like every other change the employee makes there.
• The offboarding timeline lists its own entries - the timeline on an offboarding's page shows the latest 100 audit log entries about that offboarding, found by the record rather than by the person's name. Before, it picked them out of the organisation's latest entries, so older ones were missing.

API changes

• POST /api/v1/webhooks - subscribing to an asset.* event needs the employees:read scope, and to any other event the offboardings:read scope. audit.created is rejected like any other unknown name.
• The data each webhook event carries is now documented for every event.
• POST /api/v1/offboardings accepts an optional manager_email, and PATCH /api/v1/offboardings/:id now takes status, manager_email, or both (null or "" clears the manager). The list, get and PATCH responses include manager_email. The employee's own address is refused with 400 and code: "manager_email_is_employee". See Offboarding.
• GET /api/audit-log and GET /api/audit-log/export take offboardingId and orgEmployeeId filters. In the JSON export, target and details are now exactly as stored and hashed, with personal values encrypted, and the new target_text and details_text hold them readable. See Audit Log.

v1.4.0 - 2026-04-01

New

• Onboarding Bridge - kick off a replacement hire's onboarding checklist from a completed offboarding record. Seeded tasks are pre-filled with role and department context.
• AI Offboarding Assistant - new POST /api/ai/checklist/:id, POST /api/ai/risk/:id, and POST /api/ai/kt-summary/:id endpoints (Enterprise plan).
• Flight Risk Scoring - predictive risk scoring for employees based on tenure, engagement, and exit interview themes.

Improved

• Public API POST /v1/offboardings now fires in-app and email notifications to HR/Admin users in the organisation.
• Asset checkin/checkout workflow redesigned with barcode scan support.
• Kanban cards on the Offboarding board memoised for smoother drag interactions.

Fixed

• Paginated API responses (useOrgEmployees, useAssets, useAlumni) now correctly unwrap { rows, total } shape.
• React Router v7 future-flag warnings resolved in the client application.

v1.3.0 - 2026-03-01

New

• SCIM 2.0 provisioning - /api/scim/v2/Users and /api/scim/v2/Groups endpoints for identity providers (Okta, Azure AD).
• SIEM log forwarding - send structured security events to Splunk, Datadog, or a generic HMAC-signed HTTP endpoint.
• Compliance scheduled reports - configure automated PDF/CSV reports delivered by email on a cron schedule.

Improved

• SAML SSO now uses the maintained @xmldom/xmldom fork; removed the vulnerable xmldom package.
• API key management UI redesigned with per-key scope selection.

API changes

• GET /v1/offboardings now accepts department filter parameter.
• PATCH /v1/offboardings/:id accepts separation_type in addition to status.

v1.2.0 - 2026-02-01

New

• Self-service employee portal - departing employees can complete tasks, upload documents, and check in assets through a token-authenticated portal without a full account.
• Calendly & Google Calendar integration - schedule exit interviews with one click.
• Knowledge Transfer module - structured handover with assignee tracking and file uploads.

Improved

• DocuSign and Adobe Acrobat Sign integration now supports multi-signer workflows.
• Offboarding checklist templates can now be shared across sub-organisations.

v1.1.0 - 2026-01-01

New

• Public REST API v1 - offboardings, employees, and webhooks resources. API keys with per-scope permissions.
• Webhook system - register HTTPS endpoints to receive real-time events. Payloads are HMAC-SHA256 signed.
• HRIS integrations - BambooHR, Workday, Rippling, and ADP webhooks to auto-trigger offboardings.
• Alumni network - opt-in rehire candidate pool with searchable profiles.

Fixed

• SSRF guard added to webhook URL registration to block private IP ranges.

v1.0.0 - 2025-12-01

Initial public release of the PurpletGo platform.

Features

• Structured offboarding workflows with status tracking
• Checklist templates with task assignment and SLA tracking
• Multi-step approval chains
• Role-based access control (RBAC)
• Tamper-evident audit log
• Multi-organisation hierarchy
• Stripe billing with Starter, Team, and Enterprise plans
• Email notifications via Resend
• Google Cloud Storage for document uploads
• Two-factor authentication (TOTP)
• i18n support (English, German, Spanish, French)