Slack Canvas Retention, eDiscovery & Compliance Guide

Slack Canvas Retention, eDiscovery & Compliance Guide

A Slack canvas is a file object, not a standalone document — and that single architectural fact reshapes how retention, eDiscovery, legal holds, and audit controls work once documents move from Quip into Slack. But "file object" does not mean "file-upload retention policy." Slack maintains a dedicated retention setting for canvases and lists, separate from both message retention and file-upload retention. If your compliance policy was written for a document platform, it needs revision before migration. (api.slack.com)

If you're still choosing a migration destination, see our Quip end-of-life decision guide. If you're already committed to Slack canvases, our Quip to Slack Canvases migration guide covers the technical path.

Quip vs. Slack Canvas: Compliance Capability Delta

Before addressing each compliance domain individually, reviewers migrating from Quip need a direct comparison of what changes. (For a broader technical comparison, see our Quip vs. Slack Canvas architecture and parity map.) This table is the artifact most compliance and legal teams should review first.

The largest unrecoverable gap: Quip's comment anchoring. There is no Slack API that associates a comment with a specific canvas position. This is a permanent architectural constraint, not a roadmap item, and it affects any compliance workflow that requires reviewers to understand which document section triggered a discussion.

What Is a Canvas in Slack's Data Model?

A Slack canvas is a file object — it carries an F-prefixed ID and lives in the same data layer as uploaded PDFs, images, and snippets. There is no canvases.list API method. To enumerate canvases programmatically, you call files.list filtered to the canvas type:

curl -s "https://slack.com/api/files.list?types=canvas&count=100" \
  -H "Authorization: Bearer $SLACK_TOKEN"

files.list is paginated using cursor-based pagination (response_metadata.next_cursor). The default page size is 100; the maximum is 1,000 per call. For large workspaces, budget for multiple paginated requests and respect the Tier 3 rate limit (50+ requests per minute). No single call returns all canvases at once. (Our Slack Canvas export guide covers these API constraints in detail.)

The canvas-specific API methods — canvases.create, canvases.edit, canvases.delete, canvases.access.set, canvases.access.delete, canvases.sections.lookup — handle content operations and access grants. Discovery, retention enumeration, and export all route through the files infrastructure. If your CASB or DLP tool monitors Slack files, it may already be seeing canvases — only if it filters by filetype: canvas. Legacy connectors that exclusively look for filetype: pdf or filetype: docx will silently skip migrated Quip documents. Verify explicit filetype: canvas support with your vendor before migration.

When an eDiscovery platform pulls canvas data from Slack, it retrieves file objects like this:

{
  "ok": true,
  "files": [
    {
      "id": "F0123456789",
      "created": 1678901234,
      "name": "Q3_Strategy_Canvas",
      "title": "Q3 Strategy",
      "mimetype": "application/vnd.slack-docs",
      "filetype": "canvas",
      "pretty_type": "Canvas",
      "user": "U0123456789",
      "size": 1405
    }
  ]
}

Content is not exposed in the standard message payload. It must be downloaded via the url_private_download link in the file object (requiring an active user token or Discovery API token with files:read scope), or retrieved using canvases.getContent, which returns the full canvas as markdown or HTML to a caller with canvases:read. (api.slack.com)

How Does Canvas Retention Work in Slack?

Slack's documentation states that canvases and lists share a dedicated retention policy, separate from both message retention and file-upload retention. The policy applies to all canvases and all lists in the workspace or organization — there is no per-canvas override. (hub.slack.com)

What gets retained under this policy until manual deletion or policy-driven purge:

• Canvas content
• Version history
• Comment threads

One behavioral detail that matters for compliance: Slack's documentation states that the retention clock resets each time someone edits the canvas. If your retention policy deletes canvases after 90 days, a canvas that receives minor edits weekly will never age out under an edit-date policy. Write time-based retention from the last edit date, not creation date, and evaluate whether that is operationally appropriate for your use case.

Retention Options by Plan

On Enterprise Grid, org-level retention policies override workspace-level settings. Workspace owners cannot adjust canvas retention independently when an org-level policy is in place — a meaningful structural difference from document platforms where teams or projects can control their own retention schedules.

On paid plans, Slack can keep deleted canvases available through exports and the Discovery API, or exclude them from exports entirely, depending on the configured setting. (hub.slack.com)

How Are Canvas Comments Stored and Retained?

Slack's documentation confirms that comments on a Slack canvas are threaded messages, not inline annotations. When a user comments on a section of a canvas, that comment becomes a thread associated with the canvas. The UI shows comments next to highlighted text, but the underlying data model treats them as messages in a file conversation — not as positional annotations embedded in the document. (slack.com)

There is no Slack API that anchors a comment to a specific position inside a canvas. This is a permanent architectural constraint.

Three compliance implications follow:

1. Severed context. In Quip, comments were anchored to specific text blocks, table cells, or images — the Automation API exported documents with these anchors intact. In Slack, comment threads exist as messages associated with the canvas file, but no programmatic method identifies which sentence or section triggered the discussion. Reviewers must manually read threads and infer context.

2. Export behavior. When a canvas is exported, comments are included as references to file conversation messages, not as inline content within the HTML export. Export-processing pipelines must use file_conversations.json and the matching FC: folder to reconstruct the comment thread for each canvas.

3. Retention precedence. Comment threads are covered by the canvas retention policy. Because comments are also messages, more aggressive message retention settings may affect them. Confirm which policy takes precedence in your specific configuration before finalizing retention rules.

Regulatory Mapping: SEC, FINRA, HIPAA, GDPR

A compliance guide that never names a specific regulation is a feature summary. Here is how Slack canvas capabilities map to common regulatory frameworks. Note that Slack does not certify canvas compliance with these regulations — this analysis is based on Slack's documented capabilities and standard regulatory requirements.

SEC Rule 17a-4 / FINRA Rule 4511 (Broker-Dealers)

SEC Rule 17a-4 requires that electronic records be retained in a non-rewriteable, non-erasable (WORM) format for 3–6 years depending on record type. FINRA Rule 4511 extends similar requirements to FINRA members.

The gap: Slack canvases are not WORM-compliant natively. Canvases can be edited after creation, and the edit-based retention clock means a modified canvas may never age out under a time-based policy. To meet 17a-4, broker-dealers must archive canvas content to a compliant third-party system (Smarsh, Global Relay, Proofpoint Archive, or equivalent) that captures an immutable copy at each write event.

The practical requirement: Your archival connector must support filetype: canvas and must trigger a capture on each canvas_edited audit event, not just on creation. Confirm this with your vendor — as of this writing, connector support for canvas content varies, and some vendors capture canvas metadata without capturing canvas content.

HIPAA (Healthcare)

HIPAA's Security Rule requires covered entities and business associates to implement audit controls, access controls, and integrity controls over electronic protected health information (ePHI). If canvases contain ePHI:

• Audit controls: Enterprise Grid's Audit Logs API provides canvas_opened, canvas_edited, and access-change events. These satisfy the audit control requirement but do not capture paragraph-level edits.
• Access controls: canvases.access.set allows programmatic access management. Guest restrictions and the prohibition on external sharing of access grants provide additional guardrails.
• Integrity: Slack's EKM integration provides key-based access control, but canvases are not WORM. An edit overwrites prior content unless version history is retained.
• BAA requirement: Slack offers a Business Associate Agreement on Business+ and Enterprise Grid. Verify that your Slack agreement explicitly covers canvas content.

GDPR (EU Data Subjects)

GDPR's right to erasure (Article 17) requires that personal data be deleted upon request where no overriding legitimate interest exists. For Slack canvases:

• Canvas content can be deleted via canvases.delete or admin deletion
• A legal hold overrides deletion — a canvas under hold cannot be purged by retention policy or manual deletion. GDPR erasure requests cannot be fulfilled for held content without legal review
• Data residency: Canvases created before enabling data residency remain stored in the US. To ensure EU data residency, enable the data residency setting before migrating content into canvases
• Slack Connect: Content contributed by external participants follows their organization's settings, not yours. A GDPR subject access request covering cross-org conversations requires coordination with the external org

How Does eDiscovery Work for Slack Canvases?

The Discovery API and Audit Logs API both support canvases, but only on Enterprise Grid. Organizations on Free, Pro, or Business+ plans do not have access to the Discovery API or native legal-hold capabilities. (slack.com)

On Enterprise Grid, Org Owners can use approved eDiscovery and DLP apps to review and regulate canvas content. Slack's documentation states the Discovery API supports:

• Deleting a canvas
• Fetching the direct link to a canvas
• Fetching recently created or edited canvases
• Finding when a canvas has been edited
• Retrieving comments on a canvas
• Retrieving the version history of a canvas
• Tombstoning and restoring a canvas shared in a message

Discovery API: What a Canvas Export Payload Contains

Slack's documentation does not publish a full sample Discovery API canvas response. Based on the Discovery API's documented structure for file objects, a canvas export payload includes the following fields:

{
  "type": "canvas",
  "canvas": {
    "id": "F0123456789",
    "created": 1678901234,
    "timestamp": 1678901234,
    "name": "Q3_Strategy_Canvas",
    "title": "Q3 Strategy",
    "filetype": "canvas",
    "user": "U0123456789",
    "content_url": "https://files.slack.com/...",
    "version_history": [...],
    "comments": [
      {
        "thread_ts": "1678901300.000100",
        "user": "U0987654321",
        "text": "Reviewed — numbers updated.",
        "replies": [...]
      }
    ]
  }
}

What this payload does not contain: paragraph-level edit attribution, positional anchors for comments, or dynamic content from embedded Salesforce live-data feeds. The content captured is the static state at export time.

Discovery API exports are JSON-formatted. Legal teams typically require a third-party eDiscovery platform (Smarsh, Global Relay, Proofpoint, or equivalent) to normalize, review, and produce this data — Slack provides no internal tagging, quarantine, or review workflows. Slack also warns that partner tools vary in what parts of the Discovery API payload they fully support. Confirm canvas content capture (not just metadata) with your vendor before committing a review workflow.

Third-Party Connector Status

These statuses reflect publicly available information and vendor communications as of mid-2025 and should be verified directly. Canvas support is a recent addition to Slack's data model; connector parity is not guaranteed.

For engineering-led capture outside formal eDiscovery, Slack documents canvases.getContent, which returns the full canvas as markdown or HTML. A minimal inventory-and-capture flow:

# inventory canvases (paginated)
GET https://slack.com/api/files.list?types=canvas&limit=100
 
# capture one canvas as HTML
POST https://slack.com/api/canvases.getContent
canvas_id=F1234ABCD
content_type=html

This proves existence and captures content at a point in time, but does not replace surrounding evidence — comment threads, share events, deletion status, or legal-hold context. Treat it as a validation layer, not a primary compliance record. (api.slack.com)

What Access Events Does Slack Log for Canvases?

Slack's Audit Logs API captures a detailed set of canvas-specific events, but only on Enterprise Grid. Slack's documentation confirms the following logged events:

• Canvas created, edited, or deleted
• Canvas tombstoned or restored
• Canvas opened
• Canvas shared or unshared
• Canvas downloaded
• Canvas access granted, revoked, upgraded, or downgraded
• Canvas version history enabled or disabled
• Link sharing enabled or disabled

The audit log records who performed the action, when, and from what context. It does not capture the content of the canvas itself or granular paragraph-level edits. If your compliance regime requires auditing exact text changes or sentence-level modifications, Slack Canvas will not meet that requirement. The audit trail covers file-level operations, not document-level text changes. (api.slack.com)

Compliance Decision Tree: Which Plan Do You Need?

Do you need legal holds on canvas content?
  └─ YES → Enterprise Grid required. No alternative.
  └─ NO ↓

Do you need the Discovery API or Audit Logs API?
  └─ YES → Enterprise Grid required.
  └─ NO ↓

Do you need version history in exports?
  └─ YES → Business+ minimum, plus all-conversations export approval.
  └─ NO ↓

Do you need custom retention duration for canvases?
  └─ YES → Pro minimum (custom day count).
  └─ NO → Free tier available (1-year max retention).

Access Model and Programmatic Grants

The primary access-grant path is canvases.access.set, which accepts a canvas_id, an access_level (read, write, or owner), and either channel_ids or user_ids. Up to 20 users or 20 channels can be updated per call. The method requires the canvases:write scope. DM and MPDM channel IDs are not accepted in channel_ids. (api.slack.com)

Slack documents four meaningful access states for canvases: invite only, can view, can comment, and can edit, plus an owner-controlled limited-sharing mode. Comment-only access allows comments and reactions but not content edits. Guests can only work with canvases shared in channels they belong to. External people who can view or edit a canvas cannot grant access to others.

There are no folders in Slack. To restrict access during a legal hold or compliance audit, you must iterate through the access list and revoke permissions per user or per channel using canvases.access.delete.

On plans below Enterprise Grid, no Audit Logs API is available. Business+ exposes some audit events through the settings dashboard, but the full programmatic API is an Enterprise Grid feature.

How Do Legal Holds Apply to Slack Canvases?

Slack's documentation states that legal holds on Enterprise Grid can preserve canvases, but a canvas must meet two criteria to be captured:

1. Custodian association. The canvas was created by, shared to a held channel of, or edited by the custodian before the end of the hold period. Viewing a canvas, starring it, or being in the file conversation does not establish custodial association.
2. Activity during the hold period. The canvas must have been created, deleted, shared to a held channel, had its content edited, or had a comment created, edited, or deleted during the hold period. Being read does not qualify.

A legal hold overrides the canvas retention policy — held canvases will not be purged by age-based deletion or manual deletion while the hold is active. (slack.com)

Legal holds are user-based, not canvas-based. You place a hold on a person, and all canvases meeting the association and activity criteria are preserved. There is no method to place a hold on a specific canvas directly.

Canvases in Archived vs. Deleted Channels

Slack's documentation notes that messages and files in deleted channels are not saved by retention policies or legal holds. For canvases shared in channels:

• Archived channels: The channel's messages and files, including canvas associations, remain intact and subject to legal hold. Archiving is safe.
• Deleted channels: If the channel that associated a canvas with a custodian's hold is deleted, the preservation chain may break. The canvas content may still exist as a file object, but the hold's channel-association criterion no longer applies.

Operational rule: archive channels, do not delete them, particularly for any channel that contains canvases under, or likely to be placed under, legal hold. This is not a workaround — it is the correct operational posture given Slack's documented deletion behavior.

How Are Canvases Exported for Compliance?

Slack's documentation states that workspace data exports include the current version of each canvas in HTML format. The export contains:

• The current text-based content of the canvas
• Version history — only if your workspace or org is approved for data exports from all conversations
• Comments — included as references to file conversation messages, not as inline content
• Embedded files — included as references to channel messages containing the download URL

Only the most recent version appears in standard exports. If your workspace is not approved for all-conversations exports, you receive a point-in-time snapshot with no edit history. For regulated environments requiring version trails, this is a significant gap unless you are on Enterprise Grid with the Discovery API configured. (slack.com)

Proprietary Quip macros, embedded Salesforce live-data feeds, and dynamic charts converted into Canvas-native blocks lose their dynamic functionality in the export. The eDiscovery export captures the static state at the time of export, not the live query result. If those live feeds were material to a business decision, the export will not reconstruct them.

EKM and Data Residency

Slack's documentation states that canvases use the same EKM key process as messages and files. Two operational constraints:

• Canvases created before enabling data residency remain stored in the US, regardless of the region you subsequently select
• Newly created canvases follow the selected region after data residency is enabled
• Legal hold scope interacts with data residency: confirm with Slack whether holds applied to US-stored canvases behave identically to holds on regionally-stored canvases

For GDPR compliance or EU data localization requirements, enable data residency before migrating Quip content into Slack canvases. Post-migration enablement does not retroactively relocate existing canvas data. (slack.com)

Slack lets users print a canvas or save it as PDF. Slack's documentation warns that links break when saving to PDF from the desktop app — use a browser if you need active links. Treat print-to-PDF as a convenience fallback, not a compliance record.

Slack Connect: Cross-Organizational Compliance Scope

Slack Connect introduces a compliance gap that deserves its own treatment. When your organization uses Slack Connect channels with external partners, the following applies:

• Your retention and export settings apply only to content created by your own members. External participants' messages, canvas edits, and comments follow their organization's retention and export settings.
• A canvas your member creates in a Connect channel is subject to your settings. A canvas an external participant creates in the same channel is subject to theirs.
• Legal holds placed on your custodians capture your members' activity in Connect channels, but not the external participants' contributions.
• You cannot audit external participants' canvas access events through your Audit Logs API. Those events appear in the external org's audit log, not yours.

For enterprises with active cross-organizational workflows in Slack Connect, this means any eDiscovery matter involving external-facing conversations requires coordination with the external organization's legal and IT teams. There is no technical mechanism in Slack to compel or retrieve external participant data unilaterally.

Enterprise Grid: Org-Wide Sharing, Not Per Workspace

Slack's documentation states that canvas sharing settings on Enterprise Grid are managed at the organization level. Org Owners and Admins control canvas sharing policies for all workspaces in the organization. It is not possible to manage canvas sharing at the workspace level on Enterprise Grid. (slack.com)

This means:

• A workspace admin cannot independently restrict or loosen canvas sharing
• Sharing restrictions (e.g., "only canvas owners can share") apply uniformly across all workspaces
• Version history settings can also be managed at the org level

For teams migrating from a document platform where sharing was controlled per folder, per team site, or per project, this is a governance model change. One org-wide policy replaces workspace-by-workspace controls. (See our Enterprise Grid governance guide for managing post-migration defaults.) Design your org-level policy to accommodate your most restrictive use case, then evaluate whether that creates friction for other teams.

The Quip Extraction Clock

Once a Quip subscription expires, you have roughly 90 days of read-only access before all extraction paths close. The three-phase wind-down confirmed by Salesforce: (help.salesforce.com)

1. Read-Only (90 days): Users can log in and view content. The API accepts read requests but write endpoints fail. You cannot tag documents for export or correct metadata during this phase.
2. Blocked Logins (30 days): No access through the UI or API. Your data still exists but you cannot reach it. If a legal hold is issued during this window, you cannot fulfill it.
3. Data Deletion (~30 days): Salesforce permanently deletes all content. It is unrecoverable.

The total window from subscription expiry to deletion is approximately 150 days, but your functional extraction window is only the first 90. Do not plan extraction for the read-only phase.

Extraction mechanics at scale: Salesforce's Quip Admin API bulk export is asynchronous and rate-limited by default to 36,000 documents per hour. It does not provide a single export of all company data in native folder structure. You must enumerate thread IDs first, then request exports and poll for completion. Large enterprise extractions — tens of thousands of documents — can take weeks. (help.salesforce.com)

For detailed guidance on getting data out of Quip, see our Quip export guide.

What to Verify Before Your Compliance Review

If your team is migrating from Quip into Slack canvases, a compliance reviewer will need specific answers. This checklist distinguishes between what Slack's documentation confirms and what you must independently verify in your configuration.

Rewriting Your Policy Before You Migrate

The safest policy sentence you can write: a Slack canvas is governed as Slack content, not as a standalone document repository. Once that principle is established, the rest follows.

A defensible policy rewrite requires four structural changes:

1. Define the record unit as the canvas plus its version history and comment threads, because Slack retains those together until deletion or policy expiry. Do not define a canvas as equivalent to a document file — it is not.

2. Write time-based retention from the last edit date, not creation date. Document that this means actively-edited canvases will not age out under a duration-based policy unless you add supplementary controls (for example, a quarterly review of canvases not archived to a WORM system).

3. Address deleted canvases explicitly. Decide whether deleted canvases must remain discoverable through exports and the Discovery API, and configure the "keep deleted content available for export" setting accordingly.

4. Set retention centrally on Enterprise Grid. Slack's org-level canvas-and-list retention applies to every workspace. Document that workspace administrators cannot create exceptions.

What you must not promise in policy language:

• Per-canvas retention rules (Slack does not support them)
• A public API that exports inline comment anchors (the architectural constraint is permanent)
• Workspace-level sharing governance on Enterprise Grid (org-level policy only)
• WORM compliance for canvas content without a third-party archival system
• Complete eDiscovery coverage of Slack Connect channels without external org cooperation

If your existing retention policy was written for a document management system — with per-folder retention, inline commenting, granular sharing controls, and native version archival — it will not map 1:1 to Slack's canvas model. The gaps require explicit documentation and, in regulated industries, third-party tooling to close. For financial services firms subject to SEC 17a-4 or FINRA 4511, the absence of native WORM support is not a configuration gap — it is a platform limitation that requires an archival solution as a condition of deployment.