Request privacy actions and governance evidence
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#overview.
Handle a customer who asks for a copy of their records and then wants eligible data erased. Create distinct export and erasure requests: the first delivers the approved data, while the second stops the relevant processing and tracks cleanup and permitted retention.
Before acting, establish the requester’s identity and authority, the application and customer concerned, the requested data categories and the allowed recipient. The request reference carries progress through conversations, files and connected providers; you do not have to infer completion from one deleted resource.
Available today: Use the privacy or account contact supplied by your application operator or contracting party for a request. Individual resource APIs are linked where available. Account-wide privacy requests, audit exports, configurable retention, regional controls, key IP restrictions and a published webhook address list are planned; no self-service governance console is offered by this guide.
1. Separate a copy request from reset or erasure
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#request-types.
Different actions have different scope and consequences. Describe the outcome you want before authorizing work:
| Action | Outcome | What to include in the request |
|---|---|---|
| Access request | Obtain the data and associated information covered by the approved request | Exact person, application and requested data categories |
| Portability or contractual export | Receive the eligible data in a usable machine-readable form | Applicable entitlement, formats, original files and permitted exclusions |
| Profile reset | Clear selected personalization or profile data | Whether later application use may collect it again |
| Erasure request | Remove eligible data and prevent unauthorized recreation | The data and processing to stop, with any required retention exceptions |
| Withdraw optional consent | Stop future processing for the selected consent-based purpose | The exact purpose, confirmation time and treatment of existing data |
| Delete one resource | Remove the selected file, memory or other object through its supported operation | Related copies and processing that the operation does not cover |
Deleting a file or memory, resetting a conversation, disabling a notification or removing an end-user profile does not establish platform-wide erasure. A person may also have different identities in different applications or identity providers. Do not assume that matching email addresses authorize combining those records.
2. Submit the request for the identified customer
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#request-scope.
- Use the request channel supplied by the application operator or your contracting party. Complete its identity and delegated-authority checks.
- Identify the application/account and the person concerned using the identifiers that party recognizes. Include project, customer and mode where these exist in the deployment.
- Choose the action from the table above and state the data categories or time range involved.
- Receive a tracking reference and an explanation of the accepted scope, including whether further processing has been blocked.
- Retain the reference for progress, clarification and completion review.
This template can help prepare the request; it is not an API payload or proof of authority:
Request type: access / export / reset / erasure / consent change
Application and account:
Person's account identifier and identity provider, if known:
Project / customer / mode, if available:
Data categories or time range:
Purpose to withdraw, if applicable:
Authorized representative, if acting for someone else:
Requested outcome and any clarification needed:
Supply identity evidence only through the approved verification channel. Do not put passwords, API keys, full identity documents or unrelated personal records into an ordinary support message.
3. Retrieve and review the requested copy
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#export-review.
Retrieve the ready archive through the request’s private, authorized route. Match its contents summary to the approved customer and categories, generation time and formats. Open required original files: a filename list is not their content. Record whether any missing category is empty, excluded for a stated reason or still being prepared.
Save the copy only to an authorized destination. Check access expiry and early revocation; expiration of a download link does not delete the archive or retained copies. Do not forward a working link to an unauthorized recipient.
4. Follow erasure and any retained exceptions to resolution
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#privacy-progress.
After the authorized erasure request is accepted, follow its processing block and cleanup separately. The report below tells you which systems finished and what remains with a provider, backup policy or approved hold. Give the customer that actual outcome; a partial result is still useful progress without being complete erasure.
The request shows progress for conversations, memories, files, notifications and any connected providers it covers. Its status distinguishes work still in progress from completed cleanup and permitted retention:
| Reported outcome | What the request shows |
|---|---|
| Received or awaiting verification | Whether the request is authorized; receipt alone does not mean processing stopped |
| Accepted and further processing blocked | Which scope and purposes are blocked, and the acknowledgment time |
| Running or partial | Which systems completed, which remain unresolved and the next recovery step |
| Active-system cleanup complete | Whether restricted backups, provider retention or approved holds remain |
| Retained under an exception | Data category, approved basis, permitted use and applicable review or expiry |
| Failed, unsupported or uncertain | The affected system and who will resolve it; this is not a completed erasure |
| Fully resolved | Evidence accounting for every required system and any final approved treatment |
After a processing block is acknowledged, Travila stops new processing attempts in that scope. Earlier requests already sent to an external provider remain tracked until their outcomes are known. Delayed jobs and backup restores preserve the erasure restriction rather than bringing erased data back into use. Completion time depends on the request and any provider or retention obligations; no universal deadline applies.
Variant: stop optional personalization without closing the account
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#consent-and-retention.
When a user only wants to stop optional personalization, change that purpose’s consent rather than deleting their account. Review the confirmed effective state, then decide separately whether existing personalization data should be retained, reset or erased. Required unrelated service remains usable.
Review optional purposes separately, such as memory extraction and use, location enrichment, marketing notifications and cross-customer improvement. A device permission or one notification preference does not establish consent for every processing purpose. Cross-customer content improvement is off by default. You can use required functionality without agreeing to unrelated optional purposes.
Withdrawal stops both new extraction and further consent-based use for the selected purpose. Its effective state is separate from whether existing records have been retained, reset or erased.
For retention, choose a policy by data category and purpose. Its status accounts for holds, provider copies, backups and cleanup still pending. A single deletion date or general retention label does not describe every data copy. Use only the policy and commitments actually approved for your account.
Variant: investigate who changed an account resource
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#audit-evidence.
For a suspected credential change, choose the project, resource and time window, inspect the actor and action outcome, and export the permitted evidence for the investigator. Include failed or pending changes in the account history.
Record the permitted recipient before exporting evidence. Request the action outcome as well as the authorization decision: an allowed operation may still have failed or remained pending.
Filter the audit history to the account and actions you need, inspect an individual event, or export a bounded set. The view identifies its coverage, update time, retention and known gaps. A partial export should not be treated as a complete account history. Sending audit events to your security monitoring system (SIEM), or embedding them in your application, requires a separately authorized setup. The existence of audit records does not establish a certification.
Before connecting: meet location and network requirements
Status: Upcoming — not yet available.
Section: DOC-CP-governance-privacy#region-and-network-controls.
For regional processing, confirm the offered region and its coverage across storage, computation, backups, support access and onward transfers. The chosen region is fixed for that project; changing regions requires a separately authorized migration. See Workspaces and projects. A branding setting, endpoint name or preferred-region label does not prove a data-location commitment.
For server traffic, prepare the public source IPs or CIDRs your account needs, including failover paths. An IP restriction applies to that credential and stays in place during rotation. Confirm the authorized human recovery route before enabling a restriction that could lock out the application. No address list or enabled restriction is supplied by this guide.
If your webhook receiver requires source allowlisting, obtain the deployment's verified, versioned egress address list and change policy before configuring your firewall. Do not derive a permanent range from one observed delivery. Source-IP matching supplements HTTPS and webhook signature verification; an address alone does not authenticate the delivery or its intended account.
Continue with Files, Project secrets and Console administration for the individual supported operations and their limitations.
Document ID: DOC-CP-governance-privacy. Section identities and revisions.