Skip to main content

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.
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

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 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 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.
  • 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. 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.

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 alongside the retention policy read-back described in the retention guide. For a subject-wide request, close the loop with the certificate runbook named above instead.