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.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
- Open the message’s detail page from Messaging, or from its thread in the inbox.
- Pick Redact PII in the action row. If the action is absent, one of the eligibility rules above applies.
- Read the confirmation dialog — it spells out that the purge is one-way — and confirm.
- The page reloads with the body and both numbers replaced by the redacted marker, while status, segments, and pricing read as before.
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.- Open the received message from the inbox thread — it is eligible immediately; there is no delivery state to wait for.
- Pick Redact PII and confirm. The body and both phone numbers are erased at once.
- Auditability survives. The row keeps its timestamp and its
receivedstatus 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. - Pull the
message.redactedentry from your audit export for the spill file: it names the operator who confirmed the purge and the time they did.
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 actionmessage.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.
Related
- Configure per-domain retention windows — the scheduled sweep this action sits beside.
- Retention windows and deletion — the cross-store model of what sweeps flip and what survives.
- Per-Domain Data Retention Policy — the API contract for the windows.
- Data Subject Requests — contact-scoped access and erasure.
- Proof-of-Deletion Certificate Runbook — closing a subject-wide erasure with signed evidence.
- Audit log guide — reading the entry the action writes.