TL;DR. In a standard Teams channel, with file sharing on for the connection, SlackBridge copies files from Teams into Slack as real files. In a private or shared channel it usually announces them by name instead, because those channels normally keep their files in their own SharePoint site that nothing in SlackBridge's existing permissions reaches. To turn real file copying on, a SharePoint or Global administrator grants SlackBridge read access to that one channel's site, and SlackBridge works out which sites need it and writes the command. There is no way to do it once for the whole organization. Two kinds of channel need no grant: private channels Microsoft has already moved to the team's site, and shared channels hosted by another organization, which you cannot grant at all. Pasted and copied images already come through everywhere file sharing is on, because Teams stores those with the message rather than in SharePoint.
The short version
With file sharing on for the connection (the default for Full Integration installs; Core Bridging cannot copy files at all), a file posted in a standard Teams channel arrives in Slack as a real file you can open. A file posted in a private or shared channel arrives as a line of text naming it instead.
That is not a bug, and it is not about your Slack side. It is about where Microsoft keeps the file.
| Channel type | Where Teams stores the file | What Slack gets today |
|---|---|---|
| Standard | The team's own SharePoint site | The real file |
| Private | Usually its own separate SharePoint site | The file's name |
| Shared (Teams Connect) | Its own separate SharePoint site | The file's name |
SlackBridge can read the team's site, because you granted it access to the team when you installed it. A private or shared channel's site is a different thing that your grant never covered, so Microsoft refuses the download and SlackBridge falls back to telling people in Slack what was posted. Nothing is lost and no message is dropped, but nobody in Slack can open the file.
What already works, with no action
Pasted and copied images come through everywhere file sharing is on, including private and shared channels. When someone pastes a screenshot straight into the Teams message box, Teams attaches the image to the message itself rather than filing it in SharePoint, so it never touches the site that is out of reach. If most of what your team shares is screenshots, you may not need anything on this page.
The gap is specifically attached files: anything added with the paperclip, or dragged in from a folder.
Turning on real file copying
Availability. We are rolling this out now. The permission it needs is being added to the SlackBridge application, and until that is done the grants below have nothing to attach to. Contact support and we will tell you where your tenant stands and start you off.
Making this work takes one grant per channel, run by an administrator in your own Microsoft tenant.
What you are granting
SlackBridge asks for Sites.Selected, a Microsoft permission that by itself grants nothing. It opens no site until one of your administrators names one.
Be precise about what that does and does not guarantee, because your security reviewers will be. Sites.Selected is the mechanism, not the boundary. The same mechanism can be used to hand an application write or even full control, and it can be pointed at any site collection in your tenant. What actually bounds SlackBridge is the grants your administrators make, which is why we publish the exact command and ask for Read on named channel sites.
Separately, and unchanged by any of this, SlackBridge already reaches the SharePoint sites behind the teams you connected it to, through the Microsoft Teams permissions you consented to at install. That is how files copy in standard channels today. This page is about reaching the extra sites that private and shared channels keep their files in.
We do this rather than ask for Files.Read.All, which would let SlackBridge read every file in your organization. That is a reasonable thing for your security reviewers to refuse, so we do not ask for it.
Be aware of what the grant does cover: read access to a site is read access to that site's whole contents, not only the file that was posted in the channel. For a channel site that is the channel's files, which is normally exactly what you want, but it is worth knowing before you grant it.
The three steps
1. SlackBridge adds the permission. We add Sites.Selected to the SlackBridge application. Nothing changes for you yet.
2. Your Microsoft administrator re-consents. SlackBridge's consent screen will list the new permission. Until this happens, the grants in step 3 have nothing to attach to, so do step 2 before step 3.
3. A SharePoint or Global administrator grants the channel sites. Ask SlackBridge support for your channel site list. We check each of your private and shared channels by actually trying to read it, and send back the exact script for the ones that need a grant, with your real site URLs already filled in.
The script looks like this, once per site:
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/Engineering-design-review" -Interactive -ClientId $adminAppId
Grant-PnPEntraIDAppSitePermission -Site "https://contoso.sharepoint.com/sites/Engineering-design-review" -AppId $slackBridgeAppId -DisplayName "SlackBridge" -Permissions Read
It needs the PnP.PowerShell module, and $adminAppId is an app registration of your own that you use for PnP PowerShell. That one is yours, not ours.
SlackBridge cannot run this for you, by design. Granting a site permission requires Sites.FullControl.All over your whole tenant, which is a far broader power than the one we just declined to ask for. Your administrator already has it. We are not asking you to give it to us.
Once a grant is in place, file copying from Teams into Slack starts working for that channel on the next file, provided file sharing is on for the connection in the SlackBridge dashboard (it is on by default for Full Integration installs). There is nothing to redeploy. A read grant does not enable sending files from Slack into that channel; that direction stays announcement-only in private and shared channels.
Two mistakes that produce a grant that does nothing
Both of these succeed without an error and leave file copying exactly as broken as before, which makes them worth reading twice.
- Granting the wrong application.
-AppIdmust be SlackBridge's application (client) id. It is the same value in every tenant, and it is in the script we send you. It is not the SlackBridge service principal's object id from your own directory, which is different in your tenant and looks equally plausible. - Granting the team site instead of the channel site.
Sites.Selectedhas no wildcard and no inheritance. A grant on.../sites/Engineeringdoes not reach.../sites/Engineering-design-review. The channel's own URL is the one that counts, and it is the one in the script we send you.
Each new channel needs its own grant
There is no way to grant this once for the whole organization without going back to the broad, read-everything permission. A private or shared channel that keeps its files in its own site needs a grant of its own, so a channel created next month may well need one before its files copy.
Not every channel does. Private channels that Microsoft has already moved to the team's site need nothing, and shared channels hosted by another organization cannot be granted by you at all. Both cases are covered below.
If a file stops copying in a channel that used to work, or a newly created channel never copies any, that is the likely reason. Ask us for an updated script and it will cover whatever is new.
Two exceptions worth knowing
Private channels Microsoft has already moved. Microsoft has been changing private channels so that their files live in the team's site rather than a separate one. A private channel that has already moved is readable with no grant at all, because SlackBridge can reach the team's site already.
Shared channels hosted by someone else. A Teams Connect channel belongs to whichever organization created it. If that is not you, its files live in their SharePoint, and no grant your administrators make can open it. The organization hosting the channel would have to do it. We flag these rather than hand you a command that cannot work.
You do not have to work out which of your channels are which. We test each channel by actually reading it, and only ask for a grant where reading genuinely fails because of permissions. If a check is inconclusive, for example because Microsoft was rate limiting us at the time, we say so and retry rather than ask you to grant something on a guess.
Sending files the other way
This page is about files travelling from Teams to Slack. Files going from Slack into a private or shared Teams channel are a separate question, with a different answer, and read access does not enable them. See Can SlackBridge bridge a private or shared Microsoft Teams channel? for what bridges in each direction.