---
title: "Slack Canvas Governance on Enterprise Grid: Post-Migration Guide"
slug: slack-canvas-governance-on-enterprise-grid-post-migration-guide
date: 2026-10-01
author: Rishabh Makhar
categories: [Slack Canvas, Migration Guide, From The Migration Trenches]
excerpt: "Four canvas settings, all org-level on Enterprise Grid, and the sharing default that undoes migrated access controls. A technical admin guide."
tldr: Slack Canvas on Enterprise Grid has four org-level admin settings. The default sharing posture lets any editor re-share migrated content — lock it down before announcing the migration.
canonical: https://clonepartner.com/blog/slack-canvas-governance-on-enterprise-grid-post-migration-guide
---

# 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.

> [!WARNING]
> **Canvas sharing is open by default.** On Enterprise Grid, the sharing restriction is off — anyone with edit access to a canvas can grant access to anyone else in the org. After a migration that carried per-document access controls from a source system, this default undoes your access model. Change it before announcing the migration is complete.

## 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:

| Setting | Exact admin label | Default | Scope on Grid |
|---------|-------------------|---------|---------------|
| **Version history** | "Show canvas version history and allow restoration" | Enabled | Org-level only |
| **Sharing restriction** | "Only allow canvas owners to share canvases with other people and channels" | Off (unrestricted) | Org-level only |
| **Update messages** | "Disable canvas update messages" | Off (messages enabled) | Org-level, with workspace delegation |
| **Printing** | "Anyone with view or edit access to a canvas can print it" | Enabled | Org-level only |

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.

> [!TIP]
> **Ownership matters.** If your migration creates canvases under a bot or service account, transfer ownership to the original document owners via the [`canvases.access.set` API](https://clonepartner.com/blog/blog/slack-canvas-access-after-migration-canvasesaccessset-guide) (required scope: `canvases:write`) with `access_level: owner` before enabling the sharing restriction. Otherwise, nobody except the bot can share anything. If a canvas is assigned to a deactivated user, governance becomes significantly harder — verify every user ID in your source system maps to an active Slack Grid user before migration.

## 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.

| Setting | Workspace override on Grid? |
|---------|----------------------------|
| Version history | No |
| Sharing restriction | No (explicitly documented) |
| Update messages | Yes — workspace owners can disable if org-level allows |
| Printing | No |

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](https://clonepartner.com/blog/blog/slack-canvas-vs-sharepoint-architecture-limits-and-migration) 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](https://clonepartner.com/blog/blog/how-to-preserve-version-history-in-knowledge-base-migrations).

### 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](https://clonepartner.com/blog/blog/slack-canvas-api-limits-that-break-bulk-migrations). 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.

```bash
# 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.

> [!NOTE]
> **No org-wide canvas query exists.** On Enterprise Grid, `files.list` requires a `team_id` when called with an org-level token. You must query each workspace individually and merge results to get a complete picture.

## 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:**

| Event name | Triggered by |
|------------|-------------|
| `canvas_created` | New canvas created |
| `canvas_edited` | Canvas content modified |
| `canvas_deleted` | Canvas deleted |
| `canvas_shared` | Canvas shared to a channel or user |
| `canvas_access_added` | User or group granted access |
| `canvas_access_revoked` | User or group access removed |
| `canvas_linksharing_enabled` | Link sharing turned on for a canvas |
| `canvas_linksharing_disabled` | Link sharing turned off for a canvas |
| `pref.allow_canvas_version_history_changed` | Org-level version history setting changed |

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:**

| Action | API method | Required scope |
|--------|-----------|----------------|
| Enumerate workspaces | `admin.teams.list` | `admin.teams:read` |
| List canvases | `files.list?types=canvas` | `files:read` |
| Transfer ownership | `canvases.access.set` | `canvases:write` |
| Verify content sections | `canvases.sections.lookupByTitle` | `canvases:read` |
| Edit canvas content | `canvases.edit` | `canvases:write` |
| Monitor governance events | Audit Logs API | `auditlogs:read` |
| eDiscovery / DLP | Discovery API | `discovery:read`, `discovery:write` (Slack-approved) |

For a deeper look at the Grid migration process itself, see our [Slack Enterprise Grid migration guide](https://clonepartner.com/blog/blog/slack-enterprise-grid-migration-the-complete-2026-technical-guide). If you're migrating specifically from Quip, our [Quip to Slack Canvases guide](https://clonepartner.com/blog/blog/quip-to-slack-canvases-migration-the-official-salesforce-path) covers the data mapping and content fidelity details. For broader destination evaluation, the [Quip end-of-life decision guide](https://clonepartner.com/blog/blog/where-to-move-documents-after-quip-retires-2027-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.

> Need help governing canvas content after a large-scale migration? ClonePartner handles the permission mapping, ownership transfer, and post-migration audit so your access model actually holds.
>
> [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Can you set canvas sharing policies per workspace on Enterprise Grid?

No. Slack's documentation explicitly states it isn't possible to manage canvas sharing at the workspace level on Enterprise Grid. The sharing restriction is org-level only. The one canvas setting that supports workspace-level override is update messages.

### What are the default Slack Canvas admin settings on Enterprise Grid?

Version history is enabled, sharing restriction is off (anyone with edit access can share), update messages are enabled, and printing is enabled. The sharing default is the most consequential after a migration because it lets editors redistribute content beyond the original access list.

### How do you list all Slack Canvases using the API?

There is no canvases.list endpoint. Use files.list with types=canvas. On Enterprise Grid with an org token, you must pass a team_id for each workspace and merge results — there is no org-wide files.list call. The endpoint is Tier 3 rate-limited at 50+ requests per minute.

### Can a public channel make an invite-only canvas visible to everyone?

Yes. If an invite-only canvas is shared in a public channel, it becomes visible to everyone in the workspace or Enterprise organization. Invite only hides the canvas from people it hasn't been shared with, but does not stop downstream resharing unless limited sharing is enabled.

### What happens to document permissions when migrating to Slack Canvas?

A migration can map source-system ACLs to canvas-level sharing (owner, editor, viewer). But Slack's default sharing setting lets any editor grant access to anyone else in the org. Enable the sharing restriction at the org level before or immediately after migration to preserve your access model.