What permissions does SlackBridge ask for, and why?

TL;DR. SlackBridge requests two permission sets: a Slack OAuth bot token with fifteen scopes (channels, chat, users, reactions, files) 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 Mail, Calendar, or chat-send permissions, and never requests Files or Sites permissions on Microsoft 365. The two Slack file scopes are requested at install so a new workspace can share files without a second approval round.

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:

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, Calendar, Notes, or Tasks permissions on either platform, and any administrator can switch file sharing off for a connection at any time. The scope is intentionally narrow to messages, channels, files shared in bridged 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.

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.

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 request OneDrive or SharePoint permissions. Files attached to Teams messages are announced by name and type. When file sharing is on for a connection, the bridge reads that channel's files through the team permissions already granted, purely to relay them; nothing else in OneDrive or SharePoint is accessed.
• 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 (15)

Slack scopes SlackBridge does not request

• im:* (direct message channels) - not used by SlackBridge.
• mpim:* (multi-party DMs) - not used.
• User-token scopes of any kind - SlackBridge never acts as an individual Slack user; messages and reactions are always posted by the bot.
• 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:

1. Delegated permissions act on behalf of a signed-in user. The user's individual permissions limit what the app can do.
2. 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:

---

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:

1. In the SlackBridge dashboard, open the Teams connection.
2. Click Upgrade to Full Integration.
3. Send the resulting consent link to your Microsoft 365 Global Admin.
4. After admin re-consent, the connection's tier flips to advanced, the broader token cache is invalidated, and Full Integration features unlock.

SlackBridge's own in-app upgrade flow is one-directional: there is no "Downgrade to Core Bridging" button. That is because Microsoft's /adminconsent endpoint always requests every permission registered on the app, and there is no incremental-consent API for application permissions. So SlackBridge cannot programmatically ask Microsoft to grant a narrower set than what the Full Integration app registration declares.

That limitation applies only to SlackBridge's in-app re-consent flow. It does not mean the granted permissions are permanent. A Microsoft 365 admin can narrow the permissions manually, as described next.

Narrowing permissions after a Full Integration install

If you consented to Full Integration and later want to operate on the smaller Core Bridging surface, you do not have to delete and recreate the connection. A Microsoft 365 admin can revoke the four advanced-only write permissions directly in the Microsoft Entra admin center. These four permissions are the entire delta between Core Bridging (6 permissions) and Full Integration (10):

Three of these four are used only during automated setup (uploading and installing the bot, adding members). Group.ReadWrite.All is the exception: besides creating a Team at setup, it is what copies a file across at runtime, so revoking it stops file copying on any connection that has file sharing on. Files then fall back to being announced by name and type.

Message bridging itself is unaffected either way. Steady-state bidirectional bridging uses only the six Core Bridging permissions plus the Microsoft Bot Framework, which authenticates with its own bot credentials rather than Microsoft Graph. Revoking the four advanced permissions does not break bridging.

If switching file copying off is what you actually want, do it in the SlackBridge dashboard for that connection rather than by revoking a tenant-wide permission.

To revoke them:

1. Sign in to Microsoft Entra admin center (entra.microsoft.com).
2. Go to Enterprise applications and open the SlackBridge (Full Integration) app.
3. Select Permissions, then the Admin consent tab.
4. Select a permission you want to remove, open its ... menu, and choose Revoke permission.
5. Repeat for each of the four permissions listed above.

A few things to know about this path:

• The connection keeps running under the Full Integration app registration. The tier label does not automatically flip to Core Bridging; the connection simply operates with fewer granted permissions than the app declares.
• Revoking does not block future re-consent. An admin can re-grant any of these permissions later (for example, the next time you want SlackBridge to auto-provision a Team).
• Dashboard health behavior: after a manual revoke of these four permissions, the SlackBridge dashboard treats the connection as healthy on the core permissions and notes that the advanced setup features (auto-Team-creation, auto-bot-installation, automated member management) are unavailable.
• Adding more later still works on the core six. Upgrading your plan, connecting additional Slack workspaces, and bridging more channels into a Team SlackBridge is already installed in all run on the six Core Bridging permissions. You only need to re-grant the four advanced permissions (a one-click admin re-consent you can reverse again afterward) when you want SlackBridge to auto-create a brand-new Team, auto-install the bot into a Team it has never been in, or add and remove team members for you. For the bot-install case you can also install the SlackBridge app into the Team manually instead of re-granting.

If you want to remove SlackBridge's access entirely rather than just narrow it, see the revocation steps below.

---

How do I revoke SlackBridge's access?

Each platform has its own revocation path. The Slack path stops everything in that workspace at once. The Microsoft path takes two steps, described below, because the two directions of travel authenticate differently.

Microsoft 365

A Global Administrator can:

1. Sign in to Microsoft Entra admin center (entra.microsoft.com).
2. Navigate to Identity → Applications → Enterprise applications.
3. Search for SlackBridge (Core Bridging) or SlackBridge (Full Integration).
4. 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, which stops relaying from Microsoft Teams into Slack. Existing bridged messages remain in both Slack and Teams - revocation does not delete history.

That is the first of the two steps. Deleting the enterprise application does not stop relaying from Slack into Microsoft Teams, because those messages are posted by the SlackBridge bot using SlackBridge's own credentials rather than a token issued by your tenant, and it needs only the conversation reference it already holds for that channel. To close that direction as well:

5. In Microsoft Teams, open the team → Manage team → Apps.
6. Find SlackBridge and select Remove.

Do both and the bridge is closed from the Microsoft side in both directions.

Slack

A Workspace Owner or Admin can:

1. Visit https://<your-workspace>.slack.com/apps/manage.
2. Search for SlackBridge.
3. 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 click Disconnect on a connection. That deletes the connection and its channel mappings and discards SlackBridge's cached tokens for the tenant, so relaying stops in both directions immediately - it is the fastest way to stop a bridge.

Be clear about what it does not do: Disconnect does not revoke your Microsoft consent. It is a change on the SlackBridge side only and calls no Microsoft revocation API, so the SlackBridge enterprise application stays consented in your tenant until an administrator deletes it in Entra using the steps above. If your goal is to remove the grant itself, for example to close out a security review, do it in Entra and do not rely on Disconnect.

---

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.

Can I reduce SlackBridge's permissions after granting Full Integration?

Yes. SlackBridge's in-app upgrade is not reversible in-app (Microsoft has no incremental-consent API for application permissions), but a Microsoft 365 admin can narrow the granted permissions manually in the Entra admin center without deleting and recreating the connection. Revoke the four advanced-only write permissions (Group.ReadWrite.All, AppCatalog.ReadWrite.All, TeamsAppInstallation.ReadWriteForTeam.All, TeamMember.ReadWrite.All) under Enterprise applications, SlackBridge (Full Integration), Permissions, Admin consent. Steady-state bridging continues on the six Core Bridging permissions, so revoking them does not break the bridge. The connection keeps running under the Full Integration app registration, and the SlackBridge dashboard treats it as healthy on the core permissions while noting that the advanced setup features are unavailable.

If I narrow the permissions, can I still add more channels or workspaces later?

Yes, for almost everything. Connecting additional Slack workspaces is independent of your Microsoft permissions, since it uses Slack sign-in rather than Microsoft Graph. Bridging additional channels into a Team that SlackBridge is already installed in runs on the six Core Bridging permissions. Upgrading your plan only raises your channel and connection limits and does not change any Microsoft permission. You only need the four advanced permissions again for the automated setup conveniences: having SlackBridge create a brand-new Team for you, auto-installing the bot into a Team it has never been in, or having SlackBridge add or remove team members for you. One of the four, Group.ReadWrite.All, is additionally used at runtime to copy files, so a connection with file sharing on needs it kept. Each of those is a one-time re-consent by a Microsoft 365 admin that you can revoke again afterward, and for the bot-install case you can install the SlackBridge app into the Team manually instead of re-granting.

Does SlackBridge request access to email, files, or calendars?

SlackBridge does not request Mail, Calendars, Notes, or Tasks permissions anywhere, and does not request Files or Sites permissions on Microsoft 365. The two Slack file scopes (files:read, files:write) are requested at install, so a workspace can share files across a bridge without a second authorization round. Channel files are read and written through the team-level permissions the Microsoft administrator already granted; nothing else in OneDrive or SharePoint is touched. Copying files needs Group.ReadWrite.All, which only the Full Integration tier grants, so a Core Bridging connection announces files by name and type and never copies them. An administrator can turn file sharing off for any connection from the SlackBridge dashboard.

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. SlackBridge stops receiving Microsoft Graph tokens immediately, which halts relaying from Microsoft Teams into Slack.

That single step does not close the bridge completely. Messages going from Slack into Microsoft Teams are posted by the SlackBridge bot, which authenticates with SlackBridge's own credentials rather than a token from your tenant, so they keep arriving until the SlackBridge app is also removed from the team (Teams → the team → Manage team → Apps → SlackBridge → Remove). Do both to close the bridge from the Microsoft side. For an immediate stop in both directions, ask SlackBridge support to disable the channel mapping.

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:

1. The specific permission(s) in question
2. Whether you are evaluating the Core Bridging or Full Integration tier
3. 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.