Data retention

leadmaps applies a retention policy to each workspace. Owners and admins can review or change it in Settings > Retention. Until a workspace saves its own policy, the platform defaults apply.

Workspace retention controls

Data class	Platform default	Allowed range
Product events	365 days	30 to 3,650 days
Sessions	365 days	30 to 3,650 days
Session replays	30 days	7 to 365 days
Identified user profiles	730 days	90 to 3,650 days
Workspace audit history	2,555 days	365 to 3,650 days

The cleanup process removes expired rows in bounded batches so it does not compete with live collection. Re-running the process is safe. Session replay cleanup removes both the replay record and its stored replay bytes.

Workspace audit history has an additional append-only compliance guard. A configured audit period never weakens that guard. Audit removal requires the separate operator-approved compliance path for the deployment.

Integration operational data

Temporary authorization records are removed when their explicit expiry time passes. Other completed Integration Hub operational records follow the workspace’s product-event retention period.

Cleanup applies only after work has reached a terminal state. It does not remove active connections, rules, object links, synchronization cursors, queued or retrying work, leased work, unresolved inbound receipts, or pending credential revocations.

This distinction prevents a shorter retention period from interrupting a live delivery or causing a completed action to run again.

Customer health and churn-autopsy data

Customer health is a selected-workspace private beta. Its operational cleanup follows the same product-event retention period.

Eligible operational records include:

• Completed settings-change retry receipts.
• Customer automation deliveries that were acknowledged, or were explicitly dead-lettered after delivery retries ended.
• Minimal customer-transition delivery references after every related job is terminal and outside the retention window.
• CRM lifecycle import receipts that were applied or dead-lettered and are no longer leased.
• Inactive hashed CRM reconciliation state when no pending import depends on it.

Queued, retrying, leased, pending, and processing records are not removed by this cleanup.

Trusted lifecycle events, customer-health snapshots, reviews, cited evidence, feedback, rollout history, and workspace audit history are durable records. They are not selected by the operational cleanup above. Workspace deletion and subject-erasure requests still apply.

Session replay remains optional evidence. A review can link to a replay only when the workspace captured it with the required consent and the replay still exists when the review is generated. A historical citation can outlive the underlying replay. Playback is then unavailable, and the citation must be treated as missing evidence rather than a churn assumption.

Subject erasure and customer accounts

A subject-erasure request takes priority over the normal retention schedule. For customer health, leadmaps:

1. Binds an administrator-owned retry key to one normalized subject request before any deletion begins.
2. Resolves the subject while its privacy-safe identity mapping is still available and installs a one-way request cutoff for stale in-flight work.
3. Redacts the subject from immutable identity audit details while preserving the fact that processing occurred.
4. Clears only that user’s account links and membership observed at or before the request cutoff in every region that can contain the workspace.
5. Queues each affected customer account once for regeneration, so its health and reviews no longer rely on the erased membership.
6. Removes the identity mapping after the dependent cleanup succeeds.

A failed step remains pending for an exact retry. Reusing the same key with a changed subject request is refused. Unrelated account members, genuinely later consented membership, and trusted account lifecycle history remain intact. The erasure process does not write raw identifiers to receipts, fences, or logs.

See GDPR endpoints for the boundary between site-scoped companion tools and the complete managed workflow. Read Reviews, evidence, and privacy for the customer-facing evidence rules.

Regional moves

Customer data remains in the workspace’s selected data region. A regional move copies the full customer graph and verifies both row counts and content before source cleanup can begin. An active-copy marker remains in both regions during the drain window so subject erasure covers both copies. If verification differs or one required region is unavailable, cleanup or erasure completion is refused. Shared identity parent records are copied for referential integrity but are not deleted from the source as part of a workspace move.

Other retention classes

• Dead-letter queue entries use the collector’s configured dead-letter retention period.
• Monthly quota counters are retained for 13 months.
• Aggregate funnel execution artifacts expire after one hour.
• Database backups follow the deployment operator’s backup and restoration policy. Application retention does not rewrite historical backups.

This page describes product behavior, not legal advice. Choose retention periods that match your data-processing agreement, DPIA, and applicable law.