> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # On-demand message redaction > When to use the scheduled retention sweep, the per-message Redact PII action, or a subject-wide DSAR erasure — with the console walkthrough, an inbound card-number spill worked example, hold and window interplay, and the audit evidence the action writes. # On-demand message redaction Orbit removes message content on three independent schedules, and each exists for a different trigger: the retention sweep acts on everything once per window, Redact PII acts on one message the moment you confirm, and a DSAR erasure acts on every record you hold about one contact. This page walks the per-message action — eligibility, what it erases and keeps, an inbound spill work-through, and how it composes with holds, windows, and your evidence trail. > [!WARNING] > > These are platform controls, not legal advice. Whether an > on-demand redaction discharges a particular obligation — a spill > notification, an erasure request, a contract — depends on your > regulators and your counsel's reading of them. *** ## 1. Which erasure control when | Control | Scope | Timing | Reach for it when | | - | - | - | - | | **Message-body redaction window** — [retention guide](https://docs.orbit.devotel.io/guides/settings-data-retention.md) | Every message in the workspace | Hourly sweep, once past your window | Your standing data-minimization posture; nothing to do per message | | **Redact PII** — message detail page, this guide | Exactly one message, sent or received | Immediate on confirmation | A spill to contain now, or a targeted request naming one message | | **DSAR erasure** — [Data Subject Requests](https://docs.orbit.devotel.io/compliance/dsar.md) | Every record about one contact | Executor ticks after the cooling-off window | A data subject exercised the right to erasure over their whole record | The three compose. Redacting one message does not satisfy an open DSAR; a DSAR does not wait for a window; the sweep skips rows already redacted by hand. When the scope is "everything, over time" the sweep is the instrument; when it is "this one row, now" Redact PII is; when it is "this one person, everywhere" the erasure workflow is. *** ## 2. Eligibility The action requires an **owner or admin** role. Every other role simply never sees it; the API behind the button enforces the same gate. * **Sent messages** become eligible once they reach a terminal delivery state: delivered, read, failed, undelivered, rejected, or bounced. A message still queued or in flight is not eligible, so a redaction can never race an in-flight delivery receipt. * **Received messages** are eligible from the moment they land in your inbox. Inbound messages became eligible in October 2026, matching the action's long-standing behavior for sent ones. * **Already redacted** rows show no action; the API treats a repeat call as a safe no-op. *** ## 3. Walkthrough 1. Open the message's detail page from **Messaging**, or from its thread in the inbox. 2. Pick **Redact PII** in the action row. If the action is absent, one of the eligibility rules above applies. 3. Read the confirmation dialog — it spells out that the purge is one-way — and confirm. 4. The page reloads with the body and both numbers replaced by the redacted marker, while status, segments, and pricing read as before. **Erased on confirm:** the message body; any media attached to the message; the sender's and the recipient's phone numbers, replaced by a redacted marker. **Kept on confirm:** status; segment count; price and currency; carrier errors and delivery receipts; the billing rows built from those facts. The split is deliberate: a compliance purge must not corrupt the ledger. Billing and dispute lookback keep working on a redacted row. *** ## 4. Worked example: a card number arrives inbound A customer texts a card number to your support number, and your spill policy says card data may not persist in a messaging store. 1. Open the received message from the inbox thread — it is eligible immediately; there is no delivery state to wait for. 2. Pick **Redact PII** and confirm. The body and both phone numbers are erased at once. 3. Auditability survives. The row keeps its timestamp and its `received` status inside the thread, so the conversation still reads as a sequence. The **Messages** list, the delivery log, and any export now show the redacted marker in place of the body and the marker in place of the numbers, with segment count and price intact so the row still reconciles. 4. Pull the `message.redacted` entry from your [audit export](https://docs.orbit.devotel.io/compliance/audit-export.md) for the spill file: it names the operator who confirmed the purge and the time they did. If your retention window is long, note that nothing else in the workspace was touched: unlike the sweep, the action reaches exactly one row. *** ## 5. Interplay with holds, windows, and DSAR * **Legal holds.** A hold is a litigation-preservation instruction: it exempts held records from the retention sweeps for as long as it stands. Redact PII is instead an immediate operator erasure. Order matters — place the [legal hold](https://docs.orbit.devotel.io/compliance/legal-hold.md) *before* you redact: the action is one-way, and a hold placed afterwards preserves the metadata but not content that is already gone. Recording holds — what a hold defers and what it does not — are in [Recording integrity and legal hold troubleshooting](https://docs.orbit.devotel.io/troubleshooting/recording-integrity-and-legal-hold.md). * **The retention sweep.** The sweep runs once an hour and redacts everything past your message-body redaction window; Redact PII does not consult the window and acts at once. Both leave the same row state, and the sweep skips rows you redacted by hand. Choose by scope, not by strength. * **DSAR.** A subject's erasure request covers everything you hold about them — every message, call, and record — and closes with the signed [proof-of-deletion certificate](https://docs.orbit.devotel.io/guides/compliance-dsar-erasure-certificate-runbook.md). Redacting a single message is a targeted response, not a subject-wide answer, and a per-message erosion of consent never substitutes for the workflow. Reconciling both is your [DSAR process](https://docs.orbit.devotel.io/compliance/dsar.md). *** ## 6. Evidence Every confirmation writes an audit entry with the action `message.redacted`, naming the acting operator and the timestamp. The row itself keeps its billing-grade metadata; the audit entry proves the erasure happened. Export the chain through [audit export](https://docs.orbit.devotel.io/compliance/audit-export.md) alongside the retention policy read-back described in the [retention guide](https://docs.orbit.devotel.io/guides/settings-data-retention.md). For a subject-wide request, close the loop with the certificate runbook named above instead. *** ## Related * [Configure per-domain retention windows](https://docs.orbit.devotel.io/guides/settings-data-retention.md) — the scheduled sweep this action sits beside. * [Retention windows and deletion](https://docs.orbit.devotel.io/concepts/retention-windows-and-deletion.md) — the cross-store model of what sweeps flip and what survives. * [Per-Domain Data Retention Policy](https://docs.orbit.devotel.io/compliance/data-retention-policy.md) — the API contract for the windows. * [Data Subject Requests](https://docs.orbit.devotel.io/compliance/dsar.md) — contact-scoped access and erasure. * [Proof-of-Deletion Certificate Runbook](https://docs.orbit.devotel.io/guides/compliance-dsar-erasure-certificate-runbook.md) — closing a subject-wide erasure with signed evidence. * [Audit log guide](https://docs.orbit.devotel.io/guides/audit-log.md) — reading the entry the action writes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.