Retention, removal and deletion

Transcript retention by plan#

In Privacy & Anti-fraud → Transcript retention, select Keep full transcripts for from one day up to the effective plan maximum, then Save retention. New conversations use the saved period.

Decide the policy with the team that reviews and follows up on support. A maximum is available capacity for retaining full history, not an instruction to keep everything for that long. Staff should know the selected period and where the stored-until date appears on a conversation. Use creation time when reasoning about the assigned window; repeatedly opening a transcript does not extend it. A retention-setting change affects newly created conversations and cannot reconstruct expired data. If the business has a longer-running case, identify the separate authorised case record rather than assuming the chat will remain its permanent archive.

What transcript-expiry processing removes#

Readable conversation content and the metadata needed to account for service usage have different lifecycles. Retention removes message text and attached context, invalidates the conversation, clears descriptive fields and scrubs linked Action inputs, results and identity proof. Internal handoff contact, summary and conversation copies are scrubbed with the expired conversation; limited delivery and audit metadata can remain. The customer-facing view already refuses expired access even if the scheduled worker has not processed every record yet. A surviving delivery status or usage total is therefore not evidence that a readable transcript survives. Ask about the precise record type when investigating a retention issue.

Records with separate lifecycles#

A support email already delivered to your company's mailbox is no longer only a record inside Reesponder. Your business controls that mailbox and its own retention procedure. The same applies to authorised exports and operational records created in connected systems. Service-side expiry cannot recall an email or undo a completed provider operation. Map the actual copies before promising a deletion outcome: transcript, internal handoff payload, external email, Action payload, limited run metadata, provider case and accounting fact. This makes it possible to direct the request to the responsible system rather than treating all copies as one database field with one timer.

Context field flags are not a deletion timer#

For a context integration, distinguish the browser map, accepted server-side conversation values and the field definition. Calling clearContext() removes values from the widget's current in-memory map. It does not revoke an already attached server value, reset the conversation or delete a delivered support record. A retention mode named ephemeral should not be explained as a guarantee of browser-only storage; accepted values can be stored for the conversation's use until cleanup. Send only what the task needs and clarify any stricter requirement through the appropriate processing discussion before integration. Avoid placing identity secrets in context as a shortcut to account verification.

Website removal and workspace closure#

Use website removal when retiring a domain from an otherwise continuing workspace. Remove the publishing path too, so visitors are not served a dead snippet from a theme or cache. Website removal revokes that site's active credentials and removes its website-specific Knowledge, while shared sources and past usage have their separate lifecycle. Workspace termination is broader and can schedule deletion after twelve days. Required accounting facts may be retained separately from deleted service content. A workspace revived through the supported verified-payment process must not be deleted by an obsolete termination job, but that recovery does not restore transcripts already purged under their normal expiry.

Ask for the appropriate data operation#

State the request precisely: access to a recent support exchange, correction of business information, deletion of a particular personal record, removal of a website or closure of a workspace are different tasks. A visitor should normally contact the business they spoke to, which decides the purpose of that support interaction. An administrator contacting Reesponder should supply enough safe identifying information to locate the workspace and record type. Do not attach unrelated private transcripts, tokens or full payment credentials. Reesponder can then assist through the processing relationship described in the Data Processing Agreement, rather than guessing what a browser-storage reset was intended to accomplish.

Separate billing, identity and content clocks#

Keep a lifecycle map with a distinct row for each clock. A six-hour visitor window governs support accounting; it is not the full transcript period. A ten-minute code and thirty-minute identity grant govern Action proof; neither makes the conversation permanent. A ten-minute pending proposal governs permission to execute that proposed operation, while an interrupted running write can become unknown after fifteen minutes. Administrative Action tests have a twenty-four-hour cleanup. These clocks can overlap without extending one another.

Use the map when a user reports that something disappeared or stopped working. Ask whether the missing item is a proposal, verified state, readable transcript or private test record. Then compare the relevant creation and expiry evidence instead of changing unrelated settings. A valid billing window can coexist with expired identity, and a retained transcript can remain readable after its billing window ended. An operation already accepted by an external system needs its own outcome review even if its local payload later expires. The appropriate repair follows the failed boundary, not a generic instruction to preserve every record for longer.

Retire a website through its publishing and service controls#

For a retired domain, identify the installation owner: shared custom layout, Shopify theme/app path or WordPress plugin. Stop publishing the loader through that owner and clear relevant cached pages. Then apply the appropriate service disconnection or website removal so stale public copies cannot rely on active credentials. A WordPress plugin being disabled merely stops its local output while preserving a connection; supported disconnection is a separate state. Uninstall cleanup can make a best-effort remote request, so verify the service state rather than assuming a removed ZIP guarantees remote revocation.

If the workspace continues for another site, review shared Knowledge before deleting material used by both. Website-specific material and credentials follow the retired site, while past usage and conversation history follow their own lifecycle. Keep a safe record of the retirement time, affected domain and remaining sites. Check a fresh public request to the old layout, including a deep link that may have cached HTML. This process is an installation retirement, not automatic subscription cancellation or an immediate purge of every historic business record. Use the separate billing and data-request routes for those distinct intended outcomes.

Locate the exact records involved in a data request#

Begin a request inventory with the business, website, approximate interaction time and safe case reference. List the record locations actually used: support transcript, accepted context, Action payload, handoff contact/summary, delivered email and any provider case. Identify the specific requested operation, such as access to a recent exchange or deletion of a particular record, without treating a broad phrase like "remove my data" as permission to erase another customer's case. Use the authorised business and service process to establish the requester and scope.

Record the result for each location separately. A transcript already purged cannot be recreated, a delivered message is controlled by its receiving business, and a completed provider operation is not undone by local content deletion. Some limited accounting or delivery facts have a different purpose from readable personal content. If a processing requirement needs clarification, raise it through the private review path before promising a specific outcome. The public Data Processing Agreement describes the processing relationship, while the technical inventory helps identify what that relationship concerns in your implementation. Keep unnecessary private attachments out of the request itself.

Example: one request and several record locations#

Consider a customer who asks the business to remove a recent conversation about a return. The business should identify the conversation and any linked case or delivered email, then apply the appropriate authorised request process to each record. If the transcript already expired, it cannot be reconstructed merely to satisfy a request for a copy. If a returns case still exists in the business's system, that is a separate review. A cookie-preference change stops future optional analytics under that control, but does not identify or delete the returns record. Keeping those distinctions clear prevents both an incomplete deletion claim and an unnecessary disclosure of unrelated data.

Verify the outcome and keep safe evidence#

For a retention review, document the selected transcript period, creation and expiry of relevant records, internal linked payloads and downstream copies. For a removal, verify the correct site's credentials are revoked and its public template no longer publishes the script. For account closure, record termination and the applicable cleanup schedule without promising immediate destruction of every financial fact. Use the current Terms, Privacy Policy and Data Processing Agreement to distinguish service data from independent legal or business obligations. The check is about the specific record and control, not whether one generic Delete button was clicked.