< Back to Blog

Ask for Less, earn more trust: scoping your app for the Slack Marketplace

May 19, 2026
Rosanne UsseryDevelopment Engineer III @ Slack

Less Is More: A Slack Approach to Scopes

Good permissions protect your users, simplify your app, and make the path to Marketplace listing straightforward. When you submit your app for review, both workspace admins and Slack’s review team evaluate your permission list. They both ask the same question: does this app need everything it’s scoped for?

The principle: least privilege

To make the best Slack app, request the minimum scopes it needs to function. When you submit your app for review, you’ll need to provide a reason why your app needs those scopes. In this context, bare minimum is a good thing. Asking for more permissions than you need opens your app up to a lot of issues. So keep it simple, keep it safe. And make it secure from the start. You can always update it later. 


Let’s take an example: if your app posts a daily summary to a channel, it needs chat:write. But that’s all it needs. It doesn’t need channels:read for that job.

Choosing between bot and user token scopes

Every scope belongs to either a bot token or a user token. Bot token scopes are tied to your app’s identity and work independently of any individual user. User token scopes are tied to the person who authorized your app, and actions taken with them appear as that person.

For most functionality, bot token scopes are the right choice. Apply user token scopes only when the action genuinely needs to come from the user’s perspective, like reading their group DMs or posting as them.

As you can guess, user token scopes carry more weight. They grant access attached to a real person’s identity and permissions. 

Writing scope justifications

When you submit your app, you’ll need to write a justification for each scope. The review team reads every one. Connect each scope to the feature that requires it. Make sure that the scopes you’re requesting are appropriate for the bot or user token associated with it. You’ll need to  include a clear reason for each scope in your submission.

For example, saying “Allows the app to read channel information” just restates the scope definition. Instead when justifying the scope try something more specific: “We use channels:read to list channels so users can select where to post notifications”.

Every scope should trace to a shipped feature the reviewer can test or see demonstrated. And these are for shipped features only; justifications that reference planned or unbuilt functionality won’t pass.

Scopes that require extra attention

Some scopes exist for legacy or specialized purposes and aren’t supported for new Marketplace submissions. These include: identity.*, workflow.steps:execute, admin.*, and triggers:*. If your app uses any of these, you’ll need to migrate to their current granular equivalents.

Other scopes receive closer review because they grant broad access to workspace data. Scopes like *:history and those providing extensive workspace access require you to demonstrate your data handling and retention practices. 

Additionally, apps that request these broad scopes alongside AI face additional scrutiny. Keep in mind that slack data cannot be used to train LLMs regardless of which scopes your app requests.

Required vs. optional scopes

Not every scope needs to be granted at install. Some scopes may be optional to install or to use later. Considering which scopes are required vs optional gives the users a granular control over their permissions. 

Optional scopes enhance the experience but don’t complete it. If your app breaks without a scope, it’s required. If a feature works fine without it but is better with it, that’s optional.

Slack lets you separate scopes into required (granted during installation) and optional (requested later when the user accesses a specific feature). However, keep in mind that the same review criteria apply to both.

When using optional scopes, support a reinstallation flow so users who decline optional scopes can grant them later. You’ll also need to clearly communicate on your landing page what each optional scope enables. Check out this post on optional scopes for a more detailed introduction. 


Further Reading:

Previous Post
4 min read

Less is more: a Slack approach to scopes

Next Post
4 min read

Your app, their data: security practices every Slack Developer needs