Slack Canvas Governance on Enterprise Grid: Post-Migration Guide

Slack Canvas Governance on Enterprise Grid: Post-Migration Guide

Slack gives Enterprise Grid admins exactly four canvas-level settings: version history, sharing restriction, update messages, and printing. On Grid, three of those four are org-level only — no per-workspace override. The sharing restriction is off by default, meaning anyone with edit access to a migrated canvas can grant access to anyone else in the org. If you've just landed tens of thousands of documents from a source system like Quip, this default effectively undoes whatever access model you spent weeks mapping.

This guide covers what each setting does, what the defaults are, why the sharing default creates immediate post-migration risk, how to inventory canvases programmatically when Slack's API doesn't offer a dedicated canvases.list endpoint, which OAuth scopes each API call requires, what happens to canvas permissions when channels are archived, how Slack Connect intersects with canvas governance, and what monitoring looks like with the Discovery API and Audit Logs.

What canvas admin settings does Slack expose?

Slack exposes exactly four admin-configurable canvas settings. Canvases are surfaces built into Slack where members can create and share fully-formatted content. Owners and admins can manage access to canvas version history, and turn off canvas update messages for channel and DM canvases. Here is the complete list with exact admin labels and defaults:

These four settings are the entire admin governance surface for canvases. There is no per-canvas admin override, no folder-level policy, and no API to set these programmatically at the org level. All four are configured through the admin dashboard under Organization Settings → Settings → Organization Settings.

Important: These same four settings apply equally to Slack Lists, which share the same admin surface as canvases. If your migration includes structured list data alongside documents, the sharing restriction, version history, update messages, and printing controls apply identically to Lists. Admins who assume Lists have a separate governance panel will miss this.

On Pro and Business+ plans, all four are workspace-level settings. On Enterprise Grid, they move to the org level.

Why is sharing the first setting to change after a migration?

Post-migration overexposure is a second-hop problem, not a landing problem. The migration itself maps source-system ACLs to canvas-level sharing correctly — the right users get edit or view access. The risk starts the moment those users can redistribute access beyond the original audience.

By default, anyone with permission to edit a canvas can grant others access to view or edit it, but you can restrict this so that only the canvas owner can grant access to others. That's a reasonable default for organically created canvases where the creator controls distribution. It is the wrong default for migrated content.

Here's the access model with the default (unrestricted) sharing posture:

• People with edit access can open a canvas or list and grant others view or edit access (unless limited sharing is on), plus make changes and add comments.
• People with comment-only access can add comments and emoji reactions, edit or delete their own comments, but can't make changes to the canvas itself or grant access to others.
• If a canvas or list owner limits sharing, only owners can grant access to other people. People with the link to the canvas or list will be able to request access.

So your carefully migrated per-document ACLs become suggestions rather than boundaries. One editor re-sharing a sensitive canvas to a public channel blows the access model open.

Quip-to-Canvas permission model comparison. In Quip, only users with Full Access can share a document or modify its sharing settings — this is documented in Quip's permission model under the "Full Access" role, which is distinct from "Can Edit" and "Can View." Slack Canvas is looser by default: anyone with edit access can grant access, and owners can optionally lock sharing down per canvas — but it's opt-in, not enforced. Salesforce has confirmed that Quip-to-Canvas conversion itself does not grant elevated access to new people; the risk is that Slack's permissive default makes manual widening easy after the fact. The behavioral delta — Quip Full Access required to share vs. Slack edit access sufficient to share — is the governance gap your post-migration controls must close.

Do not confuse Invite only with a fixed ACL. Slack's general access defaults to "Invite only," which hides the canvas from people it hasn't been shared with. That does not stop downstream resharing by people who already have access unless limited sharing is enabled. If an invite-only canvas is shared in a public channel, it becomes visible to everyone in the workspace or Enterprise organization.

The fix: Enable "Only allow canvas owners to share canvases with other people and channels" at the org level before the migration lands — or immediately after, before you announce the new canvas library to users.

The trade-off is real. With this restriction on, only canvas owners can invite people. If your migration script created all canvases under a service account, that account becomes the sole entity that can share any of them — until you transfer ownership. Plan your ownership mapping before you flip the switch.

Why can't you set canvas policies per workspace on Enterprise Grid?

Because Slack designed it that way. This is a platform architecture decision, not a gap waiting to be patched.

On Enterprise Grid, a canvas is technically a file object. Files in Grid are stored at the organization level so they can be referenced across multi-workspace channels — shared channels and Slack Connect conversations. If Workspace A enforced a strict "no external sharing" policy for canvases but Workspace B allowed open sharing, a canvas attached to a channel shared between A and B would create an unresolvable permissions conflict. Slack resolves this by elevating all canvas governance to the org level.

In a nutshell, org-level settings determine the experience in Slack across the entire organization, while workspace-level settings determine the experience in a specific workspace. Org-level policies and settings lay the foundation for the Slack Enterprise Grid across workspaces.

For the sharing restriction specifically, Org Owners and Admins can manage canvas sharing for everyone in your organization. It isn't possible to manage canvas sharing at the workspace level. That language is explicit and unambiguous.

The one partial exception is canvas update messages. Org Owners and Admins can turn canvas update messages off for their organization, or allow Workspace Owners and Admins to manage update messages for their workspace(s). If canvas update messages are turned on at the org level, you can manage them for individual workspaces. This is the only canvas setting with two-tier control.

The practical impact: if you run workspaces serving different business units — an engineering workspace with open collaboration norms and a legal workspace that restricts document sharing — you cannot express that difference for canvas settings. This is flatter than most document systems. Google Drive lets admins apply sharing settings by organizational unit (OU). SharePoint can set external sharing restrictions per site collection. Slack Canvas on Grid offers no equivalent policy granularity at the workspace level.

If you need per-workspace canvas policies, your options today are:

1. Accept the org-wide setting and apply the most restrictive posture that any workspace requires
2. Compensate with per-canvas ownership controls — individual canvas owners can still toggle "Only owners can share" on their own canvases, regardless of the org setting
3. File a feature request with Slack — but don't plan your migration timeline around it shipping

Each canvas setting in detail

Version history

Canvas version history is the setting labeled "Show canvas version history and allow restoration." Anyone with permission to edit a canvas can access its revision history and restore a previous version. If you'd like, you can disable canvas version history so that only the most recent version is available. It is enabled by default. On Enterprise Grid, Org Owners and Admins configure this at Organization Settings → Canvases → Edit.

Post-migration consideration: Source-system revision history does not carry over into Slack's native version tracking. A migration script typically creates a single version — the current snapshot — as the canvas content. Canvas version history starts from the moment the canvas is created in Slack. Keep this setting on: it gives your team a safety net against accidental edits to freshly migrated content.

One caveat: if your migration strategy involves multiple delta syncs where a script updates the canvas repeatedly over several weeks before cutover, leaving version history on means users will see the raw, mid-migration states in the history. If you're migrating highly sensitive data subject to strict eDiscovery rules, verify with your compliance team whether retaining these delta states is acceptable.

Prior versions of canvases will be included in exports for customers who can export data from all conversations in their workspace or Enterprise Grid organization. Customers on Enterprise Grid can also retrieve canvas version history via the Discovery API.

What happens to canvas version history when a channel is archived or deleted? Archiving a channel does not delete associated canvases or their version history — channel canvases become orphaned (their channels array empties) and remain accessible via direct link or files.list. If a channel is deleted (distinct from archived), the associated channel canvas is deleted with it and version history is lost. This is a post-migration cleanup risk: if your remediation plan involves deleting misconfigured channels, verify no valuable canvas content is attached before proceeding.

For related context on preserving version history across platforms, see our version history migration guide.

Update messages

Canvas update messages are notifications posted to a channel or DM when someone edits an attached canvas. They are enabled by default (the "Disable canvas update messages" checkbox is unchecked).

This setting has the richest control model of the four. At the org level, admins can disable updates for org-wide channels or all channels. If canvas update messages are turned on at the org level, you can manage them for individual workspaces. Disabling canvas update messages will turn them off only for the channels in that workspace.

Post-migration consideration: If you don't disable this before a migration, you will effectively execute a denial-of-service attack on your own Slack channels. Consider a scenario where you're migrating 500 documents into a single Slack channel. Your script attaches 500 canvases, and Slack fires 500 consecutive update messages into the channel timeline. Disable update messages org-wide during the migration window. Re-enable once content has stabilized.

If your migration lands mainly as standalone canvases not attached to channels, this setting matters less on day one. Slack sends update messages for edits like new headings, new paragraphs, list additions, and completed checklist items. Slack waits five minutes after editing stops, then rolls nearby edits together for up to four hours.

Printing

Canvas printing is the setting labeled "Anyone with view or edit access to a canvas can print it." It is enabled by default. You can use your computer's print settings to save a canvas as a PDF. On Enterprise Grid, this is org-level: Organization Settings → Canvas printing → Edit.

Post-migration consideration: For organizations migrating regulated or confidential content — legal documents, HR policies, financial models — disabling printing prevents offline copies from escaping the controlled environment. If your source system restricted printing or export, preserve that restriction here.

If your organization uses Slack Enterprise Grid's native Data Loss Prevention (DLP) integrations or Enterprise Key Management (EKM), be aware that canvas printing is a potential exfiltration vector. Slack does not offer a granular toggle to disable printing for specific canvases — it's org-wide all or nothing. Evaluate whether your endpoint management (MDM) or network-level DLP can intercept print spooling if you need finer control.

You can only print canvases that were created by members of your workspace or Enterprise organization. If you don't see the option to print, the canvas may have been shared by an external person in a Slack Connect conversation, or an owner or admin may have disabled the option to print canvases.

Slack Connect and printing. Canvases shared into Slack Connect channels — channels bridging your org with an external organization — are already excluded from printing by Slack's platform rules (external-org canvases cannot be printed by the receiving org). However, this protection is one-directional: your org's canvases shared into a Connect channel can still be printed by members of your org who have access, including people whose primary workspace is a Connect partner. Review which canvases are attached to Connect channels before enabling or disabling the printing setting, since the governance posture applies to your org's members regardless of channel type.

Slack Connect: the governance vector the org-level settings don't fully cover

Slack Connect introduces external-org participants into channels where migrated canvases may be shared. The four org-level canvas settings govern your organization's members — they do not govern what external participants in Connect channels can do within their own Slack environment.

Specific risks after migration:

• Resharing by external participants: If limited sharing is not enabled, an external participant with edit access to a canvas can share it with members of their own org — outside your governance boundary entirely. The org-level sharing restriction only limits sharing actions by your own org's users.
• External visibility of invite-only canvases: A canvas with "Invite only" general access, once shared into a Connect channel, is accessible to all Connect channel members from the external org who are explicitly invited. Your audit logs will capture canvas_access_added events for external user IDs (identifiable by the external org prefix), but you won't see what those users do with the content on their side.
• Printing by external participants: As noted above, external-org participants cannot print your canvases via Slack's native print function. However, screenshot and copy-paste are not governed by any Slack admin setting.

Recommended posture for migrated canvases in Connect channels: Enable limited sharing at the org level (the sharing restriction setting), audit canvas_access_added events in Audit Logs for external user IDs immediately post-migration, and avoid attaching sensitive migrated canvases to Connect channels until your access model has been validated in a non-Connect environment first.

How do you list all canvases on Enterprise Grid?

There is no canvases.list API method. To programmatically look up a list of canvases, use the files.list method while filtering for the canvas type. Your query may look something like this: https://slack.com/api/files.list?types=canvas.

Required OAuth scope: files:read. On Enterprise Grid with an org-level token, you must also specify team_id — the org-level token alone does not default to any workspace.

On Enterprise Grid, inventory is a workspace-by-workspace loop. Use admin.teams.list (required scope: admin.teams:read) to enumerate workspaces, then call files.list with team_id for each one. There is no org-wide files.list call.

# Step 1: Enumerate workspaces
# Required scope: admin.teams:read
# Rate limit: Tier 2 (20+ requests/minute)
curl -sS -H "Authorization: Bearer $ORG_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"limit":1000}' \
  https://slack.com/api/admin.teams.list
 
# Step 2: List canvases per workspace
# Required scope: files:read
# Rate limit: Tier 3 (50+ requests/minute)
curl -sS -H "Authorization: Bearer $ORG_TOKEN" \
  --get https://slack.com/api/files.list \
  --data-urlencode "team_id=T12345678" \
  --data-urlencode "types=canvas" \
  --data-urlencode "count=100" \
  --data-urlencode "page=1"

Key parameters:

• types=canvas — filters to canvas file type; other valid types include images, spaces, snippets, gdocs, zips, and pdfs.
• team_id — required if org token is used; the encoded team ID to list files in. On Enterprise Grid, you must specify which workspace to query.
• count — results per page, defaults to 100.
• page — pagination offset, starts at 1.
• ts_from / ts_to — filter files created after or before a timestamp (inclusive). Use these to isolate the migration window instead of crawling the full workspace every time.
• user — filter by the creator's user ID.

Rate limits by call:

• files.list: Tier 3 — 50+ requests per minute, with occasional bursts permitted. Rate limits are enforced per app per workspace, so querying multiple workspaces in parallel does not compound the limit.
• admin.teams.list: Tier 2 — 20+ requests per minute. For organizations with hundreds of workspaces, paginate carefully; a 1,000-workspace org requires at minimum 1 page call but the limit parameter caps at 1,000, so very large orgs may need multiple pages.

Practical math: At 100 canvases per page and 50 files.list requests per minute, you can enumerate roughly 5,000 canvases per minute per workspace. For 30,000 canvases spread across 5 workspaces, a full inventory takes under 10 minutes — including overhead for parsing and rate-limit backoff.

Canvas IDs start with F followed by alphanumeric characters (e.g., F08ABC1234X). The response includes standard file metadata: id, name, created, user, channels, shares, and permalink.

Additional API methods relevant to post-migration content integrity:

• canvases.sections.lookupByTitle (scope: canvases:read) — retrieves sections within a canvas by title. Use this to verify that migrated content headings landed correctly, especially if your source system used structured section headers as navigation anchors.
• canvases.edit (scope: canvases:write) — applies changes to canvas content. Relevant if your migration script needs to make post-landing corrections (e.g., fixing broken internal links after a URL remapping).

For cutover validation, capture per canvas: id, title, created timestamp, owner/creator user ID, linked_channel_id, whether it is a channel canvas (is_channel_space), current shares (channels, groups, ims), is_restricted_sharing_enabled, and canvas_printing_enabled. These file-object fields turn a raw inventory into a policy audit.

If a canvas is standalone — migrated as a direct message attachment or a floating file not tied to a channel — the channels array will be empty. If your migration logic intended to map source folders to Slack channels, any canvas with an empty channels array represents an orphaned document that needs remediation.

Canvas search visibility: Canvases with "Invite only" general access are hidden from Slack search results for users who don't have access. However, for users who do have access, the canvas surfaces in search even if they've never navigated to it directly. Users migrating from folder-based systems (Quip, Confluence, SharePoint) frequently expect that access controls prevent discoverability entirely — they do not in Slack. A user with edit access can find a canvas via search and share it onward, even if they received that access passively through a channel membership.

Monitoring canvases with Discovery API and Audit Logs

For compliance teams, two Enterprise Grid-only tools provide deeper canvas visibility than files.list:

The Discovery API and Audit Logs API support canvas operations including: deleting a canvas using the API, 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, and tombstoning and restoring a canvas shared in a message.

Complete Audit Logs event list for canvas governance:

For external participants in Connect channels, canvas_access_added events will include the external user's ID — these are identifiable by the external org's team ID prefix in the user identifier. Filter for these specifically in the 30 days post-migration to detect unintended cross-org access grants.

The Discovery API may only be used for security and compliance use cases, in particular eDiscovery, archiving, and data loss prevention (DLP) applications. It's not a general-purpose admin tool. The API documentation is public on api.slack.com, but the scope is gated. To call the Discovery endpoints in production, your app needs to be approved by Slack for the discovery:read and discovery:write scopes, and the customer's Org Owner has to install the app with explicit grant on Enterprise Grid.

After a migration, the combination of Audit Logs (who shared what, when) and files.list inventories (what exists, where) gives you the closest thing to a canvas governance dashboard that the platform currently supports.

Post-migration governance: the 30-day sequence

You don't need a committee to govern migrated canvases. You need a short, disciplined loop.

Day 0:

1. Enable the sharing restriction at the org level before users discover the new content. Navigate to Organization Settings → Canvas sharing → Edit and check "Only allow canvas owners to share canvases with other people and channels." Required: Org Owner or Org Admin role.
2. Transfer canvas ownership. If your migration script used a service account, transfer ownership to the original document owners using canvases.access.set (scope: canvases:write) with access_level: owner. Verify every source user ID maps to an active Slack Grid user ID before this step — canvases owned by deactivated users cannot be re-shared by anyone except an admin acting on the deactivated account.
3. Disable canvas update messages org-wide (scope: no API available; configure via admin dashboard) if you expect remaining backfill or a wave of post-migration formatting fixes.
4. Run a full inventory using files.list?types=canvas (scope: files:read) across every workspace via admin.teams.list (scope: admin.teams:read). Compare the count against your migration manifest. Flag canvases with unexpected sharing scope or empty channels arrays.

Days 1–7:

5. Review canvases shared to public channels or very large channels first. These are the places where Slack's visibility model diverges fastest from source-system expectations — an invite-only canvas shared in a public channel becomes visible to the entire workspace or org.
6. Verify that orphaned canvases (empty channels array) are intentional or remediate their placement.
7. Audit canvases in Slack Connect channels. Pull canvas_access_added Audit Log events and filter for external user IDs. Any migrated canvas that landed in a Connect channel with an external participant who has edit access is a second-hop exposure risk. Remediate before the general announcement.
8. Use canvases.sections.lookupByTitle (scope: canvases:read) on a sample set to verify content integrity. Confirm that section headings from the source system landed as expected and that no structured content was silently dropped during conversion.

Days 7–30:

9. Monitor Audit Logs for canvas_access_added, canvas_linksharing_enabled, and other sharing events. If compliance needs go deeper than metadata, use Discovery API (scopes: discovery:read, discovery:write — requires Slack approval) or your DLP stack to inspect content and version history.
10. Re-enable canvas update messages once content has stabilized and initial post-migration edits have settled.
11. Decide on version history and printing. Configure these to match your compliance requirements before you call the migration done. If any migrated canvases are attached to Connect channels, review the printing governance note above before enabling org-wide printing.
12. Document the org-level settings. Workspace admins cannot override most canvas settings on Grid — they need to know what the org-level posture is, which settings they can manage at the workspace level (update messages only), and who to contact for changes.

OAuth scope summary for the full governance workflow:

For a deeper look at the Grid migration process itself, see our Slack Enterprise Grid migration guide. If you're migrating specifically from Quip, our Quip to Slack Canvases guide covers the data mapping and content fidelity details. For broader destination evaluation, the Quip end-of-life decision guide compares Canvas against SharePoint, Notion, and other targets.

What to lock down before users start re-sharing

Slack Canvas can be a workable destination for migrated documents, but you have to accept its governance model as it exists, not as you wish it worked. On Enterprise Grid, the important access controls are org-scoped, inventory runs through file objects, and the default sharing posture is more permissive than almost any source system. If your company needs different canvas rules by workspace, that's a destination-fit issue, not an admin-training issue.

You cannot force a folder-based permission model into a flat, file-based system without explicit compromises. Lock down the org-level sharing defaults, use files.list to audit the results, monitor with Audit Logs to catch drift, and pay specific attention to Connect channel exposure — the governance surface Slack's four admin settings don't fully address.