TL;DR. SlackBridge requests two permission sets: a Slack OAuth bot token with eleven scopes (channels, chat, users) and one of two Microsoft Graph application permission tiers — Core Bridging (six read-leaning permissions) or Full Integration (ten permissions including team and app management). Tiers are chosen at consent time. SlackBridge never requests email, file, mail, calendar, or chat-send permissions.
What's the short version?
For the broader security narrative — encryption at rest and in transit, audit logging, SOC 2 status, and the full data-flow architecture — see the SlackBridge security overview. This article focuses specifically on the permissions list.
SlackBridge needs permission on both sides of the bridge. Each platform handles permissions differently:
| Platform | Permission model | What SlackBridge asks for |
|---|---|---|
| Slack | OAuth bot scopes granted at app install by a workspace admin | 11 bot scopes (channels, chat, users) + 2 user scopes (identity only) |
| Microsoft Teams | Microsoft Graph application permissions requiring tenant admin consent | One of two tiers: Core Bridging (6 permissions) or Full Integration (10 permissions) |
The Microsoft side is the more sensitive of the two, so SlackBridge offers a tier choice. Most customers can run on the Core Bridging tier — only enable Full Integration if you want SlackBridge to create new Teams or auto-install the bot for you.
If you only remember one thing: SlackBridge does not request Mail, Files, Calendar, Notes, Tasks, or Sites permissions on either platform. The scope is intentionally narrow to messages, channels, and minimal user directory data.
Which Microsoft Graph permissions does SlackBridge request?
SlackBridge offers two tiers of Microsoft 365 permissions. The customer's IT admin chooses one when they consent to install SlackBridge. Both tiers use Microsoft Graph application permissions (not delegated user permissions), which is why they require admin consent.
Core Bridging tier (6 permissions, recommended)
Sufficient for bridging messages between an existing Teams channel and a Slack channel. Read-leaning. The smaller permission surface customers' security teams typically prefer.
| Permission | Type | Why SlackBridge needs it |
|---|---|---|
Group.Read.All |
Application | Read the list of Microsoft 365 Groups (Teams are backed by Groups) so the customer can pick which team to bridge into. |
Channel.ReadBasic.All |
Application | List channels in a team so the customer can pick which channel to bridge. |
Channel.Create |
Application | Create the bridged channel inside the customer's selected Team during the auto-setup flow. |
ChannelMessage.Read.All |
Application | Required by Microsoft to register a Graph change notification (webhook) that delivers new Teams messages to SlackBridge for bridging to Slack. |
Team.ReadBasic.All |
Application | Read team display names and IDs for the team picker UI. |
User.Read.All |
Application | Resolve the display name of a Teams user who sent a bridged message, so the message arrives in Slack attributed to the right person. |
Full Integration tier (Core Bridging + 4 more = 10 permissions)
Adds four write permissions for customers who want SlackBridge to provision Teams or manage installation automatically. Choose this only if you want auto-setup conveniences — bridging itself does not require these.
| Additional permission | Type | Why SlackBridge needs it |
|---|---|---|
Group.ReadWrite.All |
Application | Create a new Microsoft 365 Group so SlackBridge can spin up a brand-new Team end-to-end (rather than only bridging into an existing Team you already manage). |
AppCatalog.ReadWrite.All |
Application | Upload the SlackBridge Teams app to your tenant's App Catalog so it can then be installed automatically. |
TeamsAppInstallation.ReadWriteForTeam.All |
Application | Install the SlackBridge bot into a Team automatically once the catalog upload is done. Without this, an admin must install the bot manually from the SlackBridge zip file. |
TeamMember.ReadWrite.All |
Application | Add or remove team members on the customer's behalf during onboarding (used only when explicitly requested). |
Permissions SlackBridge has explicitly chosen not to request
The following permissions are sometimes requested by similar tools but are deliberately absent from both tiers:
Mail.*,MailboxSettings.*— SlackBridge does not read or send email through Exchange.Files.*,Sites.*— SlackBridge does not read OneDrive or SharePoint files. Files attached to Teams messages are linked, not downloaded by the bridge.Calendars.*,Tasks.*,Notes.*— out of scope.User.ReadWrite.All,Directory.ReadWrite.All— SlackBridge never modifies your Entra directory.ChannelSettings.ReadWrite.All— was previously listed and has been removed; not used.ChannelMessage.Send— does not exist as an application permission. Outbound messages into Teams are delivered by the Microsoft Bot Framework, which uses its own bot identity rather than impersonating a Teams user.
Which Slack OAuth scopes does SlackBridge request?
When a Slack workspace admin clicks Add to Slack, the SlackBridge bot user is granted the following bot token scopes. The bot does its work on the Slack side using these scopes; SlackBridge does not impersonate individual Slack users for messaging.
Bot token scopes (11)
| Scope | Why SlackBridge needs it |
|---|---|
channels:history |
Read messages in public channels so they can be bridged to Microsoft Teams. |
channels:read |
List public channels in the workspace so you can pick which ones to map. |
channels:manage |
Create the bridged Slack-side channel during auto-setup and invite the SlackBridge bot into it. |
channels:join |
Join an existing public channel that you select in the mapping wizard, so the bot can start receiving its messages. |
groups:history |
Read messages in private channels you have explicitly invited the bot into, for bridging to Teams. |
groups:read |
List the private channels the bot has been added to (so they appear in the mapping picker — only invited channels are visible). |
groups:write |
Create or manage a private bridged channel during auto-setup, when the customer chooses a private mapping. |
chat:write |
Send bridged messages from Microsoft Teams into Slack as the SlackBridge bot. |
chat:write.customize |
Render bridged messages with the original Teams sender's display name and avatar (so the message reads as "[Original Teams User] via SlackBridge" instead of just "SlackBridge"). |
users:read |
Resolve user IDs to display names so an @mention from Teams can be rendered with the correct Slack user's name. |
users:read.email |
Fetch the email field for the small set of users displayed in the SlackBridge dashboard's directory view. |
User token scopes (2 — identity only)
These are granted only to the SlackBridge dashboard, and only to identify which workspace you are signing in from. They do not allow SlackBridge to read any of your messages.
| Scope | Why SlackBridge needs it |
|---|---|
identity.basic |
Identify the user who is signing in to the SlackBridge dashboard (used only for dashboard authentication). |
identity.team |
Identify the Slack workspace the dashboard user belongs to, so the dashboard knows which org's bridge to manage. |
Slack scopes SlackBridge does not request
im:*(direct message channels) — not used by SlackBridge.mpim:*(multi-party DMs) — not used.files:*— files attached to bridged messages are linked, not downloaded. (See also: How do emojis bridge? — the same "linked, not stored" rule applies to file attachments.)reactions:writefor user tokens — reactions are added by the bot only, not impersonated.admin.*(any Enterprise Grid admin scope) — never requested.usergroups:*— out of scope.
Why does Microsoft require admin consent for these permissions?
Microsoft Graph has two permission models:
- Delegated permissions act on behalf of a signed-in user. The user's individual permissions limit what the app can do.
- Application permissions act as the app itself, with no signed-in user. They apply tenant-wide and are typically used by background services and webhooks.
SlackBridge needs to act on Teams messages around the clock — a webhook can fire at any time, with no user actively signed in. That is the use case application permissions exist for. Application permissions always require explicit admin consent because they grant tenant-wide access. This is a Microsoft platform requirement, not a SlackBridge choice.
If you have an organization-wide rule against any third-party app receiving application permissions, the Core Bridging tier still requires admin consent for the same architectural reason — bridging cannot be done with delegated-only permissions because the user who set up the bridge will not always be signed in.
What does SlackBridge actually do with each permission?
The permissions list above describes what SlackBridge is allowed to do. Here is what it actually does in normal operation:
| Action | Permissions used | When |
|---|---|---|
| Bridge a Teams message into Slack | ChannelMessage.Read.All (subscription), User.Read.All (sender attribution), chat:write, chat:write.customize |
Each time a message is posted in a bridged Teams channel |
| Bridge a Slack message into Teams | channels:history, groups:history, users:read (sender attribution), Microsoft Bot Framework (Bot Framework uses its own credentials, not Graph) |
Each time a message is posted in a bridged Slack channel |
| Bridge an emoji reaction | channels:history, groups:history (Slack side), ChannelMessage.Read.All (Teams side, via the same change-notification subscription) |
Each time a reaction is added or removed (see the emoji bridging map for which reactions translate) |
Bridge an @mention (as text) |
users:read (Slack-side display name), User.Read.All (Teams-side display name) — see how mentions bridge |
Each time a message containing a mention is bridged |
| Bridge a threaded reply to its parent | channels:history, groups:history, ChannelMessage.Read.All — plus the message-mapping store SlackBridge maintains internally; see how threads bridge |
Each time a reply is posted in a thread on either side |
| Show available channels in the mapping wizard | channels:read, groups:read, Channel.ReadBasic.All |
Each time you open the New Mapping dialog |
| Auto-create a paired bridged channel | channels:manage or groups:write (Slack), Channel.Create (Teams) |
Once, during the Easy Setup flow |
| List available Teams in the dashboard | Team.ReadBasic.All, Group.Read.All |
Each time you open the Teams connection picker |
| Auto-install the SlackBridge bot into a Team | AppCatalog.ReadWrite.All, TeamsAppInstallation.ReadWriteForTeam.All |
Full Integration tier only, once per Team during install |
| Sign in to the SlackBridge dashboard with Slack | identity.basic, identity.team |
Each time a user signs in to the dashboard |
Can I start with Core Bridging and upgrade later?
Yes. SlackBridge connections store the permission tier per Teams tenant. If you start with Core Bridging and later want auto-Team-creation or auto-bot-installation, an admin can re-consent with the Full Integration tier:
- In the SlackBridge dashboard, open the Teams connection.
- Click Upgrade to Full Integration.
- Send the resulting consent link to your Microsoft 365 Global Admin.
- After admin re-consent, the connection's tier flips to
advanced, the broader token cache is invalidated, and Full Integration features unlock.
You cannot downgrade from Full Integration to Core Bridging without revoking consent and starting over, because Microsoft's /adminconsent endpoint always requests every permission registered on the app — there is no incremental consent API for application permissions. To narrow the permission set, the connection must be deleted and re-created against the Core Bridging app.
How do I revoke SlackBridge's access?
Each platform has its own revocation path. Both take effect immediately.
Microsoft 365
A Global Administrator can:
- Sign in to Microsoft Entra admin center (entra.microsoft.com).
- Navigate to Identity → Applications → Enterprise applications.
- Search for SlackBridge (Core Bridging) or SlackBridge (Full Integration).
- Open the application and select Properties → Delete, or remove user/group assignments under Users and groups.
Once deleted, SlackBridge can no longer obtain Graph API tokens for your tenant. Existing bridged messages remain in both Slack and Teams — revocation does not delete history.
Slack
A Workspace Owner or Admin can:
- Visit
https://<your-workspace>.slack.com/apps/manage. - Search for SlackBridge.
- Open the app page and click Remove App.
Once removed, the SlackBridge bot token is invalidated immediately. The bot stops sending and receiving messages in your workspace.
Both at once
In the SlackBridge dashboard, the connection owner can also click Disconnect on any Teams or Slack connection, which calls the corresponding revocation API on the platform side and stops the bridge in one step.
What about audit logging on these permissions?
Every Microsoft Graph API call SlackBridge makes is logged in the Microsoft 365 Audit Log under your tenant — Microsoft handles this server-side regardless of which third-party app made the call. Search for the SlackBridge service principal name to see exactly what calls were made, when, and against which channels. SlackBridge's own internal audit log architecture (cryptographically chained, tamper-evident) is described under Security → Audit Logging.
On the Slack side, every API call by the SlackBridge bot is logged in your workspace's audit log (Enterprise Grid only) and visible to Workspace Owners under Settings & administration → Audit logs. Standard (non-Grid) plans do not expose detailed audit logs, but Slack still logs activity internally for compliance investigations.
SlackBridge maintains its own internal audit log of message bridging events with cryptographic chaining for tamper evidence, available to customers via the dashboard for incident review.
For the underlying data-handling commitments (what is stored, for how long, and where), see the SlackBridge privacy policy and the list of sub-processors. The plan-tier feature gating that some permissions enable is described in pricing.
Frequently asked questions
What Microsoft Graph permissions does SlackBridge require at minimum?
Six application permissions in the Core Bridging tier: Group.Read.All, Channel.ReadBasic.All, Channel.Create, ChannelMessage.Read.All, Team.ReadBasic.All, and User.Read.All. All require Microsoft 365 admin consent because they are application permissions, not delegated user permissions.
What is the difference between SlackBridge's Core Bridging and Full Integration tiers?
Core Bridging asks for six read-leaning Microsoft Graph permissions sufficient to bridge messages between an existing Teams channel and a Slack channel. Full Integration adds four write permissions that let SlackBridge create new Teams, install the bot automatically, and add or remove team members on your behalf. The choice is made at consent time and can be upgraded later.
Does SlackBridge request access to email, files, or calendars?
No. SlackBridge does not request Mail, Files, Calendars, Sites, Notes, or Tasks permissions on either Microsoft 365 or Google Workspace. The scope is restricted to messages, channels, and minimal directory information needed to attribute messages to the correct user.
Why does SlackBridge request Slack channels:manage and channels:join?
channels:manage lets SlackBridge create the Slack-side bridged channel during the auto-setup flow and invite the SlackBridge bot user into it. channels:join is what allows the bot to join an existing public channel that you select in the mapping wizard. Without these, every channel mapping would require a manual /invite step.
Can SlackBridge send arbitrary messages on behalf of a Teams user?
No. The Microsoft Graph application permission ChannelMessage.Send does not exist for app-only authentication and is therefore not requested. Outbound messages from Slack into Teams are delivered by the Microsoft Bot Framework using the SlackBridge bot identity, not by impersonating any Teams user.
How do I revoke SlackBridge's access to my Microsoft 365 tenant?
A Global Administrator can revoke consent at any time via Microsoft Entra admin center → Enterprise applications → SlackBridge → Properties → Delete, or by removing the assignment under Users and groups. The bot will stop receiving Graph API tokens immediately and bridged messages will halt within minutes.
How do I revoke SlackBridge's access to my Slack workspace?
A Slack Workspace Owner or Admin can remove SlackBridge at any time at https://[your-workspace].slack.com/apps/manage → SlackBridge → Remove. The bot token is invalidated immediately and SlackBridge stops receiving channel events.
Still need help?
If your security team has a specific permission concern, contact SlackBridge support and include:
- The specific permission(s) in question
- Whether you are evaluating the Core Bridging or Full Integration tier
- Any specific compliance requirement you need to meet (SOC 2, ISO 27001, HIPAA, GDPR, etc.)
We aim to respond within one business day, and your security team can request a written summary of the data flows associated with any specific permission.