---
title: "SharePoint to Slack Canvas Migration: Metadata & Permissions Guide"
slug: sharepoint-to-slack-canvas-migration-metadata-permissions-guide
date: 2026-09-30
author: Raajshekhar Rajan
categories: [SharePoint, Slack Canvas, Migration Guide]
excerpt: "SharePoint metadata and permissions don't map to Slack Canvas. This guide covers term GUID resolution, permission gaps, content triage, and API limits."
tldr: "Slack Canvas is markdown with no fields or permission inheritance — migrating from SharePoint means resolving term GUIDs, accepting permission loss, and triaging content between canvases and file uploads."
canonical: https://clonepartner.com/blog/sharepoint-to-slack-canvas-migration-metadata-permissions-guide
---

# SharePoint to Slack Canvas Migration: Metadata & Permissions Guide


# SharePoint to Slack Canvas Migration: Metadata & Permissions Guide

There is no migration tool that moves SharePoint content into Slack Canvas. This is not an oversight — it reflects a fundamental [architectural gap between Slack Canvas and SharePoint](https://clonepartner.com/blog/blog/slack-canvas-vs-sharepoint-architecture-limits-and-migration). SharePoint is a structured document management system with content types, site columns, managed metadata term stores, and hierarchical permission inheritance. A Slack Canvas is a markdown document. Its `document_content` object accepts two properties: `type` (always `markdown`) and `markdown` (the body text). No custom fields. No schemas. No permission inheritance.

Every piece of structured metadata from SharePoint has exactly three destinations in Slack: prose in the canvas body, a row in an index canvas, or intentional removal. Every item-level permission restriction either maps to a private channel, gets broadened to match an existing channel's membership, or stays in SharePoint. If you do not make these decisions explicitly before writing a single script, the migration will drift into manual cleanup and silent security loss.

This guide covers what actually happens to metadata and term GUIDs, why permissions cannot map cleanly, which SharePoint content belongs in a canvas versus a file upload, the API constraints on both sides that shape the timeline, and the failure modes that break migrations silently.

> [!NOTE]
> **API verification note:** Slack API behavior in this guide was verified against the `canvases.access.set` docs on [docs.slack.dev](https://docs.slack.dev/reference/methods/canvases.access.set/) and Microsoft Graph API v1.0. Both platforms ship breaking changes without advance notice — confirm current limits before building a pipeline. The Slack UI documents native file uploads up to 1 GB per file on paid plans, but the `files.getUploadURLExternal` API path does not publish the same ceiling in its documentation. For migration pipelines, treat the API path limit as unconfirmed and validate against a large test file before building your upload stage.

For background on exporting from SharePoint, see [How to Export Data from SharePoint: Methods, Limits & Migration Prep](https://clonepartner.com/blog/blog/how-to-export-data-from-sharepoint-methods-limits-migration-prep). For SharePoint's metadata model, see [Mastering SharePoint Information Architecture 2026](https://clonepartner.com/blog/blog/sharepoint-metadata-vs-folders-information-architecture).

## Why SharePoint metadata has no equivalent in Slack Canvas

**SharePoint metadata** is structured data applied to files and pages at multiple levels: **content types** define field schemas per library, **site columns** provide reusable field definitions across a site collection, and **managed metadata terms** from the term store supply controlled vocabularies with hierarchical taxonomies. A SharePoint document library item might carry a `Document Type` content type with site columns for `Department`, `Region`, and `Policy Status`, each backed by a managed metadata term set. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/api/resources/contenttype?view=graph-rest-1.0))

Slack Canvas has none of this. There are no typed fields, no columns, no schemas, and no taxonomy. Canvas does not support custom fields, and Slack has no list or database surface comparable to SharePoint lists.

### How to handle term GUIDs on export

SharePoint content items do not store managed metadata term labels — they store **term GUIDs**. When you export list items via Microsoft Graph (`/sites/{site-id}/lists/{list-id}/items?expand=fields`), the managed metadata column returns a lookup ID that references the hidden `TaxonomyHiddenList`, not the term store directly. The actual term GUID lives in the term store.

When moving to a non-SharePoint target, those GUIDs are meaningless. The destination has no term store, no `TaxonomyHiddenList`, and no concept of a term ID. Microsoft's own guidance confirms that imported taxonomies receive new GUIDs ([learn.microsoft.com](https://learn.microsoft.com/de-de/previous-versions/office/developer/sharepoint-2010/hh147179%28v%3Doffice.14%29)), so even reimporting into a different SharePoint tenant does not preserve original identifiers without custom PowerShell.

You must:

1. **Export the term store** as a flat lookup table — term GUID → label → parent group → term set.
2. **Resolve every taxonomy field** in every list item against that lookup during extraction.
3. **Emit the human-readable label** into whatever prose or index canvas you create.

If you skip step 1, you will get opaque IDs like `f3b2a1c4-...` in your canvas body instead of "North America" or "Active."

> [!WARNING]
> **Term GUID remapping is not optional.** Any migration script that copies SharePoint field values without resolving taxonomy lookups will produce canvases full of orphaned identifiers. Build the lookup table first and validate it against a sample batch before running a full extraction.

### Metadata flattening strategies

For every SharePoint column, decide whether it becomes visible prose, an entry in an index canvas, or an external control record. There is no fourth option.

- **Inline as prose.** Write metadata values as a header block or key-value list at the top of the canvas body. Readable by humans but unsearchable by any structured query.
- **Index canvas.** Create a dedicated canvas with a markdown table acting as a registry — one row per migrated item, columns for each metadata field. Slack canvases enforce a **300-cell limit per table** and a **1 MiB limit** on markdown content per canvas ([docs.slack.dev](https://docs.slack.dev/surfaces/canvases/)). A six-column metadata table tops out at roughly 50 rows before hitting the cell ceiling, so large libraries must be sharded by site, library, or content type.
- **Drop it.** If the metadata was only used for SharePoint views or search refiners and has no operational value in Slack, document the decision and move on.
- **External register.** Keep an authoritative metadata map outside Slack — your source-to-target mapping sheet, term GUID remap table, and dropped-field register should live in a migration workbook or database, not inside the canvas itself.

A workable mapping record looks like this:

```yaml
source_item:
  site: HR
  library: Policies
  item_id: 4821
  content_type: Policy Document
  terms:
    department:
      label: Finance
      source_term_guid: 1111...
      target_term_guid: aaaa...
target_canvas:
  mode: file_unfurl          # canvas acts as a metadata wrapper around a linked file
  index_canvas: policies-index
  rendered_fields:
    - content_type
    - department
    - owner
    - review_date
    - source_item_id
```

`mode: file_unfurl` means the canvas body contains a metadata header block and an unfurled link to the uploaded Slack file, rather than the full document text. Store the source term GUID even if the label looks identical — matching on label alone is unsafe when labels drift or duplicates exist across term sets.

### SharePoint list data: a distinct migration track

Document libraries and SharePoint lists are different extraction problems and should not be collapsed into the same pipeline. Lists may contain:

- **Lookup columns** that reference rows in other lists — these relationships have no equivalent in Canvas and must either be denormalized into prose or dropped.
- **Calculated columns** that derive values from formulas at query time — these must be evaluated during extraction because the formula itself cannot travel to Slack.
- **Person/Group fields** that store Azure AD user IDs — these must be resolved to display names or Slack user IDs before writing to canvas.
- **Multiple-value columns** that store arrays — these need explicit serialization decisions (comma-joined string, separate bullet points, or separate canvases per value).

Lists with relational structures, where rows reference other lists via lookup columns, produce the most migration complexity. Map every lookup column before extraction, decide whether to join the referenced data inline or drop the reference, and document the choice.

### Retention labels and sensitivity labels: the compliance gap

Managed metadata term GUIDs are recoverable through the resolution process described above. **Retention labels and sensitivity labels are not.**

SharePoint retention labels (applied via Microsoft Purview) define hold periods, deletion schedules, and records management rules. Sensitivity labels (applied via Microsoft Information Protection) enforce encryption, access restrictions, and data classification. Neither has any equivalent in Slack Canvas.

When content with retention labels or sensitivity labels moves to a canvas:
- The label is removed. The canvas carries no retention policy.
- Any hold that was triggered by a retention label (making the item undeletable) does not transfer.
- Encrypted content with a sensitivity label may be inaccessible during extraction unless the extracting service account has the label's usage rights.
- Regulatory obligations attached to the label — GDPR, HIPAA, financial record-keeping — remain with the organization regardless of where the content lives.

**Do not migrate labeled content without explicit sign-off from your compliance or legal team.** The technical migration is straightforward. The compliance exposure is not. For many organizations, labeled content should stay in SharePoint and be linked from a canvas rather than moved.

## How SharePoint permissions compare to Slack Canvas access

**SharePoint permissions** use a hierarchical Access Control List (ACL) model with inheritance across four levels: site, library/list, folder, and individual item. Administrators can break inheritance at any level to assign unique permissions. A single library might have 500 items where 490 inherit from the library and 10 have item-level restrictions for specific Azure AD groups. ([learn.microsoft.com](https://learn.microsoft.com/en-us/sharepoint/sites/overview-of-site-permissions-in-sharepoint-server))

**Slack Canvas access** is fundamentally flatter. The `canvases.access.set` API method grants `read`, `write`, or `owner` to channels or individual users. The hard constraints:

- It accepts a maximum of **20 `channel_ids` or 20 `user_ids` per call** (never both simultaneously). ([docs.slack.dev](https://docs.slack.dev/reference/methods/canvases.access.set/))
- **DM and MPDM (multi-party direct message) channel IDs are explicitly rejected.**
- Permissions set at the channel level apply to all channel members — there is no per-user restriction within a shared channel.
- Slack's product UI offers a **comment-only mode**, but the documented API method exposes only `read`, `write`, and `owner`. If you need comment-only from automation, test it as a manual post-migration exception. ([slack.com](https://slack.com/help/articles/15678967614611-Manage-access-permissions-for-canvases-and-lists))
- Slack user groups are not directly supported in `canvases.access.set` — Azure AD group mappings require manual resolution to individual users or channel memberships.

| SharePoint concept | Slack Canvas equivalent | Gap |
|---|---|---|
| Site-level permissions | Workspace membership | Rough analog only — no per-canvas control at this level |
| Library-level permissions | Channel-level canvas sharing | One canvas shared to one or more channels |
| Folder-level permissions | No equivalent | Canvases have no folder hierarchy |
| Item-level unique permissions | Private channel per restricted item | Only workaround; creates channel sprawl |
| Permission inheritance | None | Every canvas grant is explicit |
| Azure AD group mapping | Manual user/channel resolution | No direct API support |
| Retention label enforcement | None | Label is lost on migration |
| Sensitivity label encryption | None | Label is lost on migration; encrypted files may fail extraction |

### Why item-level permission parity is not achievable

If a SharePoint library has 30 items with broken inheritance — each restricted to a different set of users — the Slack expression is 30 private channels, each with the correct member list, each with its own canvas. That does not scale. A library with 200 uniquely-permissioned items would need 200 private channels, destroying the user experience and potentially hitting workspace channel limits.

For every item-level restriction in SharePoint, you either:

1. **Create a private channel** with the correct members and share the canvas there. Works for a small number of high-sensitivity items.
2. **Accept broader access** by sharing the canvas at the library-equivalent channel level and documenting this as a deliberate access widening.
3. **Keep the content in SharePoint** and link to it from the canvas, preserving the original access controls for sensitive items.

The practical approach is to cluster content by audience, not by original folder tree. Export the effective ACL for each candidate item using the Graph API (`/drive/items/{item-id}/permissions`), group items with identical audiences, and map those groups to Slack channels. Record every case where access becomes broader.

> [!CAUTION]
> **Permission parity must be signed off, not assumed.** Present the permission delta — what widens, what cannot be expressed — to the data owner or compliance team before migration. If the sign-off does not happen, the migration should not proceed.

### Slack Enterprise Grid: different sharing rules

Enterprise Grid workspaces have different canvas sharing behavior than standard workspaces. In Enterprise Grid, canvases can be shared across multiple workspaces within the organization, and channel federation rules affect which channels are visible to `canvases.access.set`. If you are migrating into an Enterprise Grid environment:

- Verify whether the target channels are org-level channels or workspace-specific channels — this affects which `channel_id` values are valid in the access call.
- Multi-workspace sharing requires the canvas to be created in a workspace that the target channel can access.
- Admin-level token scopes may be required for cross-workspace canvas operations.

Test `canvases.access.set` in the target Enterprise Grid environment before building the permission-mapping stage of your pipeline. Standard workspace documentation does not reliably describe Enterprise Grid behavior.

For a deeper look at auditing source permissions, see [SharePoint Permissions & Security Best Practices](https://clonepartner.com/blog/blog/sharepoint-permissions-security-best-practices-2026).

## Content triage: what becomes a canvas, what stays a file

The following table summarizes the migration path for each content type. Use this as the decision point before extraction.

| SharePoint content type | Extraction method | Target in Slack | What is lost |
|---|---|---|---|
| Modern site pages (text-heavy) | Graph `/sitepages`, parse `CanvasContent1` text web parts | Canvas with markdown body | Layout, Hero, Quick Links, embedded web parts |
| Modern site pages (web-part-heavy) | Extract title, abstract, key links only | Summary canvas + file link | Most visual and dynamic content |
| Document library files ≤ 250 MB | Graph simple download | Slack file upload + wrapper canvas | SharePoint metadata (moved to canvas header) |
| Document library files > 250 MB | Graph chunked upload session | Slack file upload + wrapper canvas | Same as above; chunked upload required |
| Files with retention/sensitivity labels | Do not extract without compliance sign-off | Keep in SharePoint, link from canvas | Nothing lost — migration blocked intentionally |
| SharePoint lists (simple) | Graph list items with expanded fields | Index canvas or external register | Calculated columns, lookup relationships |
| SharePoint lists (relational) | Graph list items + referenced list items | Denormalized index canvas or drop | All relational structure |
| Wiki-style knowledge articles | HTML/markdown body extraction | Canvas with metadata header block | None if content is plain text |
| Power Automate workflows | Out of scope — document separately | N/A | All automation |

### Modern site pages (`.aspx` with web parts)

SharePoint modern pages store their content in `CanvasContent1` JSON containing web part configurations — hero banners, quick links, embedded Power BI tiles, image galleries, custom SPFx web parts. Microsoft Graph exposes these as pages with `webParts` and `canvasLayout`. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/api/resources/sitepage?view=graph-rest-1.0))

Slack Canvas is strictly markdown — Block Kit is not supported, and there is no way to render a web part grid, an embedded iframe, or a dynamic data connection.

Pages that are mostly headings, paragraphs, and simple tables can be extracted and rewritten into canvas markdown. Pages that depend on Hero, Quick Links, embedded documents, highlighted content, or layout-driven elements should be **summarized, not converted**. Your extraction script should parse the `CanvasContent1` JSON, isolate `Text` web parts, convert the underlying HTML to markdown, and either downgrade or drop the rest. An embedded document web part becomes a URL link. A Hero web part becomes a markdown image and a text header.

Keep the title, short abstract, key links, and owning team. Drop the promise of page parity.

### Document library files (PDFs, Office docs, images)

**Files should stay files.** Do not flatten a 40-page PDF or a complex Excel spreadsheet into a canvas body.

Upload files to Slack using the `files.getUploadURLExternal` → `files.completeUploadExternal` workflow (the legacy `files.upload` was sunset in November 2025). Then create a canvas that serves as a wrapper: short description, metadata header block, owner, last review date, and an unfurled link to the uploaded file.

If Microsoft 365 must remain the system of record, Slack's OneDrive and SharePoint app lets users preview and search files in Slack while the files remain stored in their original location ([slack.com](https://slack.com/help/articles/115002272646-OneDrive-and-SharePoint-for-Slack)). Limitation: the Slack app does not currently support sharing folders or OneNote files. This path is often better for governed documents where compliance or retention policies apply, because the file never leaves the Microsoft 365 compliance boundary.

### Wiki-style content and knowledge base articles

Plain-text or lightly-formatted knowledge articles — process documentation, runbooks, onboarding guides — are the natural fit for canvases. Convert the HTML or markdown body, add a metadata header block with key fields (original author, department, last modified date, source item ID), and share to the appropriate channel.

### SharePoint workflows and Power Automate flows

Any Power Automate flows or legacy SharePoint workflows associated with the migrated content are out of scope for a canvas migration and must be treated as a separate workstream. Flows that trigger on item creation, modification, or status change in a SharePoint library have no Slack equivalent unless rebuilt using Slack Workflow Builder or a middleware platform. Document every flow associated with candidate content before migration begins. If a flow handles a compliance or approval process, do not migrate the underlying content until the flow equivalent is confirmed in the target environment.

## API constraints that shape the migration

### Platform limits reference table

| Constraint | Platform | Value | Notes |
|---|---|---|---|
| Canvas markdown content per canvas | Slack | 1 MiB | Per `canvases.edit` operation |
| Table cells per canvas table | Slack | 300 | Applies to all markdown tables |
| Channel/user IDs per `canvases.access.set` call | Slack | 20 | channel_ids and user_ids cannot be mixed in one call |
| Canvas API availability | Slack | Paid workspaces only | Not available on free plans |
| Simple file upload via Graph | Microsoft Graph | 250 MB | Above this, use `createUploadSession` |
| List view threshold | SharePoint Online | 5,000 items | Query-time constraint, not storage limit |
| Max items per list | SharePoint Online | 30 million | Storage limit; irrelevant to query behavior |
| Permission break/re-inherit blocking threshold | SharePoint Online | 100,000 items | Affects unique permission auditing on large lists |
| HTTP 429 retry guidance | Microsoft Graph | Honor `Retry-After` header | Per-request throttling survives batching |

### Microsoft Graph: 429 throttling on batch operations

Microsoft Graph returns **HTTP 429 (Too Many Requests)** when a throttling threshold is exceeded, along with a `Retry-After` header indicating the wait time in seconds. Each sub-request inside a `$batch` call is throttled individually — batching does not shield you from per-request limits. Batched failures are not automatically retried by SDK retry handlers. Throttling is enforced across multiple layers: tenant-level, app-plus-tenant combination, and service-specific (SharePoint/OneDrive). ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/throttling))

Migration scripts that enumerate large libraries and fetch item metadata in parallel will hit 429s regularly. The correct response is exponential backoff with jitter, honoring the `Retry-After` value. Ignoring 429s or retrying immediately extends the throttle window.

For re-runs after the baseline wave, use `listItem: delta` for list-backed changes and `driveItem: delta` for file-backed changes. Delta queries avoid full re-enumeration on every pass. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/api/listitem-delta?view=graph-rest-1.0))

### Microsoft Graph: the 250 MB simple upload ceiling

The Graph API's `PUT /drives/{drive-id}/items/{item-id}/content` endpoint supports files up to **250 MB**. Files larger than 250 MB require a chunked upload session via `driveItem: createUploadSession`. This matters when your extraction pipeline buffers files through Graph's download endpoints before pushing to Slack — the 250 MB boundary determines whether you can use a simple download call or need to stream in chunks.

### SharePoint: the 5,000-item view threshold

SharePoint Online enforces a **list view threshold of 5,000 items**. This is not a storage limit — lists can hold up to 30 million items — but a query-time constraint. Any API call that attempts to return more than 5,000 items from a single scope without an indexed column filter will fail or return incomplete results. ([learn.microsoft.com](https://learn.microsoft.com/en-us/troubleshoot/sharepoint/lists-and-libraries/items-exceeds-list-view-threshold))

For migration enumeration:

- Use **server-side filtering** with indexed columns to page through large libraries.
- Set `$top` to the maximum page size (up to 5,000) and follow `@odata.nextLink` pagination.
- Use **delta queries** for incremental tracking rather than re-enumerating the full library on each run.

SharePoint also blocks breaking or re-inheriting permissions on a list, library, or folder once it passes **100,000 items** — relevant if you need to audit unique permissions during extraction on very large libraries.

### Slack-side API errors to handle explicitly

Beyond the hard limits in the table above, these are the specific error responses your pipeline needs to handle:

- **`canvases.create` with content exceeding 1 MiB** returns `invalid_arguments`. The error message does not specify which argument failed. If you see this, the content size is the first thing to check. Split the canvas and retry.
- **`canvases.access.set` with a DM or MPDM channel ID** returns `channel_not_supported`. Validate channel types before building your access-set payload — filter out any channel whose type is `im` or `mpim`.
- **`canvases.access.set` with more than 20 IDs** returns `too_many_ids`. Batch your channel and user lists to 20 per call before sending.
- **`files.getUploadURLExternal`** returns `invalid_arguments` if the `length` parameter does not match the actual file size sent in the subsequent POST. Compute file size before requesting the upload URL, not after.
- **Graph 403 on sensitivity-labeled files** indicates the extracting service account lacks the label's usage rights. Log the item ID, skip it, and route it to the compliance review list rather than retrying.

## Step-by-step migration workflow

Do not attempt to read from SharePoint and write to Slack in a single synchronous process. Run the migration in distinct stages.

### 1. Audit and classify

Enumerate all SharePoint sites, libraries, and lists via the Graph API. For each item, tag it as **canvas candidate**, **file upload**, **keep in SharePoint and link**, or **do not migrate**. Flag every item with broken permission inheritance, a retention label, or a sensitivity label. Enumerate Power Automate flows associated with candidate content. Separate modern site pages, document libraries, structured lists, and labeled content before designing the target — they are different extraction tracks.

### 2. Export the term store

Build a term GUID → label lookup table covering every term set referenced by your content. Include source GUID, label, parent group, and term set path. Validate against a sample of 50–100 items before proceeding to full extraction.

### 3. Extract content and metadata

Use Microsoft Graph to pull list items with expanded fields, resolving taxonomy columns against your lookup table. Evaluate calculated columns at extraction time. Resolve person fields to display names. Download files separately, noting which require chunked upload sessions. Implement 429 handling with exponential backoff from the start — do not add it later. Pull page `CanvasContent1` JSON for modern site pages and convert text web parts to markdown. Skip labeled content flagged in stage 1 until compliance sign-off is received.

### 4. Map permissions to Slack channels

For each SharePoint site or library, identify the target Slack channel. For items with unique permissions, decide: private channel, broader access with written sign-off, or keep in SharePoint. Generate a mapping file that stakeholders can review. Explicitly document every case where access becomes broader — for example, an item previously restricted to three people that will be accessible to the 50 members of `#engineering-leadership`. Obtain written sign-off before proceeding.

### 5. Upload files

Upload document library files to Slack via `files.getUploadURLExternal` → `files.completeUploadExternal`. Compute file sizes before requesting upload URLs. Capture the returned Slack file IDs for linking in canvases.

### 6. Create canvases and set access

Use `canvases.create` with markdown content including a metadata header block. Keep within the 1 MiB content limit per canvas — split content before sending rather than handling `invalid_arguments` errors. Set access with `canvases.access.set`, batching to 20 channel or user IDs per call, validating channel types to exclude DMs and MPDMs. Embed unfurl links to uploaded files in the relevant canvases, and ensure your [naming and indexing strategy](https://clonepartner.com/blog/blog/naming-indexing-10000-slack-canvases-after-migration) is applied so users can actually find the new content.

### 7. Validate and get sign-off

Spot-check metadata fidelity, permission grants, and file accessibility across a representative sample. Review dropped fields, broken page features, and permission broadening against the mapping file from stage 4. Use Graph delta endpoints for content changed after the baseline wave. Confirm that labeled content has not been migrated without compliance sign-off. Obtain formal written sign-off before decommissioning the SharePoint source.

## What a good migration looks like

A good SharePoint-to-Slack-Canvas migration does not pretend that Canvas replaces SharePoint's field model, security model, or compliance model. It treats Canvas as a clean consumption layer for human-readable knowledge, keeps files as files, preserves the metadata that still matters as prose or an index structure, and documents — with sign-off — the compromises that cannot be avoided.

The hard part is not the text. It is the metadata that gave that text meaning, the permissions that controlled who could see it, and the compliance labels that determined how long it had to be kept. Managed metadata term GUIDs are a solvable engineering problem. Retention labels, sensitivity labels, and broken-inheritance item-level permissions are not — they require human decisions about compliance exposure before a single API call runs.

Migrations that skip these decisions do not fail visibly. They succeed quietly while silently broadening access, losing retention policy coverage, and producing canvases full of orphaned GUIDs. The audit that catches those problems arrives after the source has been decommissioned.

> Migrating SharePoint content to Slack Canvas with metadata and permissions intact is a custom engineering problem. If you need extraction scripts, permission mapping, term store resolution, and compliance label handling worked through end to end, book a call and we'll scope it.
>
> [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 SharePoint permissions be preserved in Slack Canvas?

Not with full parity. SharePoint supports site, library, folder, and item-level permissions with inheritance. Canvas access is channel-scoped via canvases.access.set, which accepts a maximum of 20 channel_ids per call and rejects DM/MPDM IDs. Item-level restrictions require creating a private channel per item, which does not scale. Permission widening must be explicitly signed off.

### What happens to SharePoint managed metadata in Slack Canvas?

Canvas has no fields, content types, or taxonomy. Managed metadata term GUIDs must be resolved to human-readable labels during extraction using a term store lookup table. The labels can be embedded as prose in the canvas body or as rows in an index canvas. The structured, queryable nature of the metadata is lost.

### Do SharePoint term GUIDs survive migration to another platform?

No. Term GUIDs are assigned by SharePoint's Managed Metadata Service and are meaningless outside that term store. Even reimporting into a different SharePoint tenant via the out-of-box CSV method assigns new GUIDs. You must build a GUID-to-label lookup table and resolve every taxonomy field during extraction.

### Should SharePoint modern pages or documents be converted to Slack canvases?

Modern pages with complex web parts should be summarized, not converted — Block Kit is not supported in canvases. Text-heavy pages can be rewritten into markdown. Document library files should stay files: upload them to Slack and reference them from a canvas with an unfurl link rather than flattening content into markdown.

### What API limits matter most during a SharePoint to Slack Canvas migration?

Microsoft Graph returns 429 errors when throttled, with each sub-request in a $batch call throttled individually. The Graph simple upload endpoint has a 250 MB ceiling. SharePoint's list view threshold blocks queries beyond 5,000 items without indexed filters. On the Slack side, canvas edits are capped at 1 MiB of markdown per call, and tables are limited to 300 cells.