Platform operators

People: a request to delete a person's data

A person can ask for their data to be deleted, or their organization’s administrator can ask for them. People is where a platform admin carries out the request. Each step is a dry run first, and every change is recorded in the portal audit log with the reason you give.

Find the person

Search for an address, a name or an account id. People also finds an account that belongs to no company any more, which the Tenants search cannot. The person’s page shows:

every company they belong to, with their company role and workspaces, Suspended when the company’s identity provider has suspended their membership, and SCIM when the company provisions them through SCIM;
the companies they have left that still hold their AI data or items they own;
how far each step of the request has got.

Before you change anything, confirm who is asking. A request from the person must come from the address the account signs in with: write a new message to that address, and act on the reply. A request from an administrator must come from an active administrator of the same company whose membership is not Suspended. Keep a record of the request outside your issue tracker, because it names a person, with the audit number each step shows.

How each step works

Opening a step runs its dry run. The dry run changes nothing. It shows how many rows each part of the step would change, what blocks the step, and anything you should know first.
A platform admin confirms by typing the word the dialog asks for and a reason. Platform support can open every dry run but cannot confirm one.
The step changes exactly the rows the dry run counted, in one transaction, and records one audit entry, whose number the portal shows. If the data has changed since the dry run, nothing is changed: the dialog shows what is different and runs the dry run again, and you confirm again.

A request from the person

The request covers every company the person belongs to. Do the steps in this order:

Step	What it does
Ownership, in each company	Lists everything they own there (dashboards, reports, Stories, models, pipelines, schedules and more), with the items that run as them, and moves it all to the member the organization names. Otherwise deactivation stops the organization’s schedules and refreshes that run as them. Their own subscriptions never move.
Deactivate	Account-wide: sign-in is refused, and every session ends at its next refresh. It can be undone from a tenant’s Users tab until the account is anonymised.
Erase AI data everywhere	Their AI conversations, feedback, saved preferences and rules, and earlier AI jobs, in every company, including companies they have left. AI usage records stay: they hold no content, and they back the AI credits billed.
Sign out everywhere	Ends every session at once, switches off API keys, revokes the apps they authorized and their remembered devices, cancels pending invitations and deletes sign-in links. When the last access token has expired (15 minutes by default), their session records, devices, passkeys, recovery codes, linked sign-ins, password and authenticator are deleted automatically. Delete credentials now does this by hand once it is due. It only brings forward the deletion that Sign out everywhere scheduled, so it is refused when there is none.
Anonymise account	Asks for the day the request arrived. The account becomes “Deleted user” with an address that no mailbox receives, and loses its picture and single sign-on identity. Their own rows (favorites, notifications, subscriptions, personal saved views, searches) and the mail sent to them are deleted. Their address is taken out of invitations, sign-ups, trial notices, content-report copies and the portal audit entries written before that day. What they made stays with their organizations, under the anonymised account.

Sign out everywhere is refused while the account is active, because the person could sign straight back in. The person’s page shows when it ran and when the automatic deletion is due. If that deletion is refused (for example, because the account was activated again in the meantime), nothing is deleted: the step is marked refused with the reason, and you run Sign out everywhere again. If it is marked overdue, run Delete credentials now. The step is marked done only when the credentials were deleted after the last Sign out everywhere, the account has not signed in since, and nothing the step ends or deletes is there again: a password set again since the deletion, for example, leaves the step not scheduled, saying how many are there, and you run Sign out everywhere again. If an earlier request deleted them and the account was used again since (it signed in again), that deletion does not count: the page shows where the new deletion stands, or marks the step not scheduled when there is none, and you run Sign out everywhere again.

Anonymise account is refused while the account is active, while it still holds AI data, or while a company still provisions the person through SCIM (marked SCIM in that company’s row). That company’s identity provider still manages them and would keep sending their name and address. Run Remove in that company first, and ask its administrator to unassign the person in the identity provider. Once the account is anonymised, neither an identity provider nor an administrator can give it a name or an address again, and no one can activate it again: a tenant’s Users tab (Activate), a company’s Admin → Users, an invitation still pending for it and an identity provider’s reactivation are all refused, saying that the account was anonymised at the person’s request.

A request from an administrator

An administrator’s request covers only their own company. Deactivation is account-wide, so do not deactivate a person who also belongs to another company. Use the actions in that company’s row on the person’s page:

AI data erases their AI data in that company’s workspaces. It works for a company they have already left.
Ownership moves what they own there, if the organization wants someone to take it over.
Remove takes them out of that company: their group, workspace and company memberships there and their SCIM identity there are removed, and their sessions in that company end at once. Their other companies and their account stay. The company’s last active administrator cannot be removed. If the company provisions people through SCIM, remove them in its identity provider too, or the next sync may add them back.
Anonymise here deletes their own rows that belong to that company and the mail sent to them there, and takes their address out of that company’s notices and invitations. It is refused while they are still an active member there or still hold AI data there.

Anything account-wide waits until the person asks themselves.

What is kept

Invoices, payments and the billing account, which belong to the organization’s subscription and which tax law requires you to keep.
Audit logs, and the portal’s record of the request itself.
AI usage records, which hold no content.
What the person made at work, under the anonymised account or with the member who took it over.
Content reports the person filed, without their name, so they can still be reviewed.
Backups, until they expire. If you restore from an older backup, apply the request’s deletions again.

Three parts are done by hand: deleting any content-report emails that name the person from the mailbox they were sent to; asking the organization to remove the person’s address from its own settings (schedules, alerts and the billing contact); and, where a company provisions the person through SCIM, asking its administrator to unassign them in the identity provider.

Tenants: a tenant’s Users tab also shows Suspended and SCIM, and each name opens the person’s People page.
Portal audit log: every step, with its reason.
Email: suppress an address if the person asks never to be emailed again.