Data subject requests
File and review a person's erasure request, manage approvals and deadlines, and inspect the resulting receipt.
6 min read
Use Settings > Governance > Data subject requests as an Admin or Owner to process a person's erasure request. Tale tracks the request, its approval and waiting period, and the result of the deletion process. Confirm the person's identity and the appropriate scope through your organization's process before filing.
File a request
- Select File request and choose the Subject by name or email. Check that you selected the intended account.
- Select the Lawful ground and write a Reason narrative that explains the request and references your internal case.
- Type
ERASEexactly, then select File request. - Open the receipt and check its status, deadline, and next required action.
Erasure permanently removes covered data; it is not a move to Trash. The receipt records the affected categories and counts, including chats, documents and uploads, preferences, feedback, notifications, usage, and audit-identifier scrubbing. It also deletes the transcripts of the standard agent runs the person started and the files only those transcripts held; the files a task keeps as deliverables stay. The erasure also deletes the separate sandbox workspaces of the agent runs the person started, even while work still runs in them, and the receipt counts them under Sandbox workspaces. A workspace counts only once the sandbox service has deleted its files, which can take a while for a large one. Until then, or while deleting them keeps failing, the receipt reads Partial with sandboxWorkspaces among its failed passes; choose Retry later, and the erasure completes once the files are gone. On Kubernetes, a workspace counts once its volume is handed to the cluster's storage provisioner; with a StorageClass whose reclaimPolicy is Retain, the volume's files stay until an operator removes the volume, although the receipt counts the workspace. A sandbox service or device that is not yet updated to this version cannot confirm the deletion, so the receipt stays Partial until it is updated.
The Model requests category covers requests to the model API and direct model calls in automations. Settled requests are removed; a request still in progress keeps the information needed to finish accounting, with the person’s identity replaced by a pseudonym. Later usage is recorded under that pseudonym. If retiring the automation run or removing the identity fails, the receipt stays Partial and the dependent usage cleanup waits for a retry.
Tasks that name the person as Reviewer lose that designation. A task review still waiting on them moves to the first eligible human fallback, the task creator or project creator, and that person is notified. On an archived task the review moves without a notification. Review decisions the person already made stay on record without their name.
An erasure leaves saved automation version content and test reports unchanged. It replaces the person's attribution with a pseudonym where they saved a version or checked its tests, deployed it, set its trigger, installed it in a project or deleted it.
Run erasure does not rewrite values copied into tests in retained automation versions. Review these authored values separately using your organization's data process. Use synthetic examples when saving a run as a test.
Check the policy before filing
| Setting | Effect |
|---|---|
| Cooling-off window (hours) | A waiting period of 0–72 hours before execution. Admins can cancel while waiting. Zero allows immediate execution once other requirements are met. |
| Require dual approval | A different admin must approve before the cooling-off window begins. The filer cannot approve their own request. |
| Daily limit per admin | Limits each admin to 1–50 filings per day. |
Only the Owner can change this policy. Stronger safeguards apply immediately; weaker safeguards are staged for 24 hours so any admin can cancel the change. Review the effective settings and any pending-change banner before relying on a new value.
Follow the receipt
| State | What to do |
|---|---|
| Pending / awaiting approval | Check whether another admin must approve or the cooling-off window must finish. Cancel or reject if the request should not run. |
| Running | Wait for the category results; do not file a duplicate request. |
| Completed | Review the recorded counts and retain the receipt with your case. |
| Partial | Inspect the skipped categories and errors. Resolve the cause before retrying. |
| Blocked | Inspect the legal hold. Covered data remains protected. The receipt names the hold that still applies; once the hold is released it says so, and the erasure continues only when you choose Retry. |
| Failed | Read the failure details. Use Retry when available; a watchdog timeout may require a new request. |
| Cancelled | No further execution is scheduled by this receipt. File a new request if the case must resume. |
An open receipt for a subject can prevent a duplicate filing. Work from that receipt rather than creating repeated requests. A retry blocked at initial filing must satisfy the current approval and waiting-period policy again. A receipt awaiting approval keeps the approval requirement captured when it was filed: turning dual approval off later does not release it.
Automation runs held during an upgrade are preserved while their earlier external actions remain unverified. An erasure still deletes the person's other eligible automation runs and reports erased and preserved counts separately. The receipt stays partial. These execution holds are separate from legal holds, and currently have no release action. Requesting a stop or retrying erasure does not clear them. An organization containing these holds also cannot be deleted.
Manage the deadline
The list shows the tracked deadline and whether it is overdue. Use Extend deadline for a justified extension while it is still available: the application permits one extension before the original deadline expires and records the reason and admin.
The deadline is a tracking aid. Your organization remains responsible for assessing the request and communicating with the person. Completing a Tale receipt does not by itself confirm deletion from unrelated external systems or backups.
Verify the outcome
Open the receipt's category counters, errors, and audit timeline. A completed action, a held category, and a failed pass have different outcomes; record those distinctions in your case. Review audit logs for the associated administrative events.