Building a Slack app: a scope-to-launch playbook

A team is already talking about your product in a channel. They paste a link, someone asks what happened to that account, and a third person opens a separate tab to go check. That tab is the gap a Slack app closes. The work your customers do in chat all day is the buying moment for an app that brings your product into the conversation, and the decision to build one starts there, not with the platform.

This is an independent playbook. PartnerMatch is not affiliated with Slack, and nothing here is an official program document. Platform requirements, scope names, and review criteria change, so treat the exact details as things to confirm in the current official documentation rather than as fixed facts. What does not change much is the shape of the work: deciding fit, choosing the right surfaces, requesting only the access you need, passing review, and listing where teams can find you. That shape is what this guide covers, in the order you hit it.

It pairs with our scope-to-launch playbooks for other ecosystems, the Shopify app playbook and the HubSpot App Marketplace, and our broader SaaS marketplace strategy guide, so you can compare what is common across platforms and what is specific to building in chat.

The 60-second version

• Decide fit first. A Slack app pays off when your users already work in chat and your product has a moment that belongs in the conversation. If neither is true, the effort may not return.
• Pick the surface to the job. Bots, slash commands, and events are different tools. Start with the one that matches the workflow, not all of them at once.
• Request the narrowest scopes. Every OAuth scope you ask for is something a workspace admin and a reviewer will question. Least privilege is easier to approve and easier to trust.
• Build for the workspace, not one user. Tokens, installs, and data are scoped per workspace, and getting that model right early saves painful rework.
• Treat review as acceptance criteria. Read the current requirements before you design and build against them, so review is a non-event rather than a scramble.
• The directory listing is a conversion surface. Lead with the workflow and outcome, show what the app does inside chat, and make support and pricing clear.
• Listed is the start, not the finish. Installs come from activation and the work after launch, not from the listing existing.

Step 1: decide whether a Slack app fits

The most expensive mistake is doing all of this work for a surface that was never going to move your numbers. Before any build, answer one question honestly: do your users already work in chat, and does your product have a moment that genuinely belongs in the conversation?

When the answer is a clear yes, a chat app meets people where they already are. A team that lives in channels would rather get a notification, run a quick command, or approve something without leaving the conversation than open another tab to do it. "Available in the directory" is also a small trust signal to a cautious buyer. When the answer is no, when your users do not live in chat, or your product only loosely touches the work they do there, the app becomes a project that costs months and returns a handful of installs.

Work through the fit before you commit:

If most of your answers land in the right column, the honest move is to hold off and revisit when the fit is stronger. We work through this kind of decision in build, buy, or partner and our marketplace strategy guide. An app is worth real effort only when there is a genuine workflow and real customer pull behind it.

Step 2: choose the right surface

A chat platform gives you several ways to show up, and they are not the same tool. The common mistake is to reach for all of them in the first version because the documentation lists them all. The better move is to pick the one surface that matches the workflow you identified in Step 1, ship that well, and add others only when a real job calls for them.

The three building blocks most apps start from:

Bots. A bot is an identity your app uses to post messages, reply in threads, and present interactive elements like buttons and menus. It is the right surface when your product needs to push information into a channel or hold a short back-and-forth. A deploy finished, an alert fired, a customer replied, and the app posts it where the team can act. Bots are also where interactive approvals live, since a button in a message is the lightest possible way to let someone confirm or reject without leaving chat.

Slash commands. A slash command is a typed shortcut that triggers your app on demand. It is the right surface when the user initiates the action. They want to look something up, kick off a task, or fetch a status without context-switching, so they type a command and get an immediate response. Slash commands are pull rather than push: the user asks, the app answers.

Events. The events surface lets your app react to things happening in the workspace, like a message posted in a channel the app is in or a reaction added. It is the right surface when your product needs to respond to activity rather than wait to be called. Events are powerful and also where over-broad access creeps in, because subscribing to everything is easier than subscribing to exactly what you need, so this is a place to be deliberate.

A quick way to choose:

The interactive-button pattern is the same human-in-the-loop idea we cover in connectors and agents: the app proposes, a person confirms, and only then does something change. In a chat surface that confirmation is a button, which is about as low-friction as an approval gets.

Step 3: request the narrowest scopes

This is the step that decides how much trust you earn and how smoothly review goes. A chat platform uses OAuth scopes to control what an app can read and do, and every scope you request is a permission a workspace admin sees at install and a reviewer questions at submission. The principle is least privilege: ask for exactly the access your features use, and nothing you might use someday.

The reasoning is the same one that makes any integration safe to ship. Broad access is a liability you carry. An app that can read every message in a workspace is a bigger risk, a harder install decision, and a more thorough review than an app that can only post to the one channel it was added to. The narrower the request, the easier every later step becomes, because there is less for anyone to worry about.

A few rules keep scopes honest:

• Map each scope to a feature. If you cannot point to the exact feature a scope enables, do not request it. A scope with no feature behind it is pure liability.
• Prefer the narrower of two options. Where a platform offers a tighter scope that covers your need, take it over the broader one, even if the broader one is more convenient to code against.
• Add scopes when features ship, not in advance. Requesting access for a roadmap item you have not built yet means carrying risk for a feature that does not exist. Ask when you build it.
• Explain why at install. Tell the admin in plain language what each permission is for. An admin who understands the request approves it; one who is surprised by it hesitates.

The same least-privilege discipline shows up on the producer side of any integration. Our guide to a partner-ready API covers scoping access from the side of the product being integrated with, and the logic is identical: grant the minimum that does the job.

Step 4: build for the workspace

A chat app's data model is organized around the workspace, not the individual user, and getting that right early saves rework that is painful to do late. An app is installed into a workspace, the tokens it receives are scoped to that workspace, and the data it can touch belongs to that workspace. Build as if every install is its own tenant, because that is what it is.

In practice this means a few things. Store the install and its tokens per workspace, so one customer's app cannot reach another's data. Authenticate using the platform's standard OAuth flow rather than asking for credentials you hold yourself. Handle token refresh and revocation cleanly, since an admin can remove your app at any time and your system has to notice and stop. And isolate workspaces at the data layer, so the boundary is enforced in your queries, not just assumed in your code.

The patterns underneath this are the same ones in any solid integration: clean authentication, scoped permissions, and isolation between tenants. Our guide on handling auth in integrations covers the auth side, and the workspace-isolation requirement is the same data-boundary discipline we cover in MCP security: one customer's data must never be reachable from another's session. The better you respect this model from the start, the fewer findings you hit at review, because most findings trace back to an install model that treated the workspace as an afterthought.

Step 5: treat review as acceptance criteria

To reach the public directory, an app goes through a review, and that review is a real gate, not a formality. The mistake is treating it as a final exam you cram for at the end. The right move is to read the current requirements before you design and build against them as acceptance criteria, so review confirms what you already did instead of surfacing surprises.

The reasoning is simple. Findings discovered at submission are expensive, because fixing them often means changing how the app handles tokens, scopes, or data, which is rework on top of finished features. The same findings caught during the build are cheap, because you build it right the first time. So you fold the requirements into your definition of done and verify against them as you go. This is the same logic as our guide to app certification without the pain: the checklist is acceptance criteria, and meeting it should be a non-event because you have been building to it all along.

The exact requirements are the platform's to define and they change, so confirm them in current official documentation. The categories serious reviews care about are stable:

Two practices make review go smoothly. First, prepare evidence, not just working code: reviewers want to understand why your scopes are the ones you chose and how you handle data, which means documentation, not only a passing demo. Second, do a self-review against the published requirements before you submit, ideally with someone who did not build the feature, so the obvious gaps get caught by you instead of the reviewer. A clean first submission saves a round trip, and round trips are where weeks go. For the engineering side, common web and API vulnerability classes are well documented by OWASP, linked at the end.

Step 6: write a directory listing that converts

Passing review gets you the right to list. It does not get you installs. The directory listing is a conversion surface, and most of them undersell the app by describing what it is instead of what it does for the person reading.

Lead with the workflow and the outcome. Someone scanning the directory is asking one question: will this make a job I already do faster or better. Answer it in the first lines, in their language, before any feature list. "Get an alert in the channel the moment a deal closes" beats "a powerful chat integration" every time, because the first names a job the team recognizes and the second makes them work to figure out if it applies.

What a listing that converts includes:

• A workflow-first headline and summary. The outcome and the job, in the buyer's words, not your internal name for the feature.
• Show the app in chat. A real screenshot of the bot posting or the command responding beats a stock graphic. People want to see what they are getting.
• The scopes, explained. Be upfront about what the app accesses and why. The admin deciding whether to install will look, and a clear explanation builds trust.
• Honest, clear pricing. Whatever your model, state it plainly. A buyer who cannot tell what it costs assumes the worst and moves on.
• Social proof. Reviews and named customers if you have them. Early on, even a handful of genuine reviews moves the next buyer.
• Obvious support. Make it clear someone is behind the app and how to reach them. Admins will not install software with no visible owner.

We go deeper on listing copy in our guides to writing a marketplace listing that converts and how marketplaces rank apps. The short version: the listing is sales copy aimed at a specific buyer doing a specific job, and the ones that convert name that job and prove the app does it.

Step 7: drive installs after you list

A common assumption is that listing is the finish line and installs follow on their own. They do not. A new listing in a large directory is one tile among many, and discovery alone will not carry it. The work after launch is what turns a listing into adoption.

The first turn of the flywheel is the hardest, so prime it deliberately. Point your own customers who use both products at the listing to seed the first installs. Ask happy customers for honest reviews, because the first few are what make the next admin comfortable. Then watch what happens after install: the metric that matters is not installs, it is active, retained workspaces, and an app that gets installed but never used is a churn risk, not a win.

The motions that drive adoption after launch:

We cover the post-launch playbook in driving installs after launch and the wider motion in our co-selling engine guide. The throughline is that the listing is the start of the work, not the end of it.

Common mistakes, and the fix

Building because the platform is big, not because it fits. The fix: confirm your users work in chat and your product has a real moment in the conversation before you commit. An app without genuine fit and pull is months of effort for a tile nobody installs.

Reaching for every surface at once. The fix: pick the one surface that matches the workflow, bot, slash command, or events, ship it well, and add others when a real job calls for them. A focused app is easier to build, review, and explain.

Requesting more scopes than you use. The fix: map every scope to a shipped feature and request the narrowest option. Every extra scope is something the admin hesitates over and the reviewer questions, and least privilege is both safer and easier to approve.

Treating the install as per-user instead of per-workspace. The fix: build the data model around the workspace, store tokens per install, and isolate workspaces at the data layer. Getting this wrong is expensive to fix after launch.

Treating review as a final exam. The fix: read the current requirements first and build against them as acceptance criteria. Findings caught during the build are cheap; findings caught at submission are rework on finished features.

Assuming installs follow the listing. The fix: seed installs from existing customers, gather reviews, instrument activation, and follow up on stalled installs. Discovery alone will not carry a new tile in a crowded directory.

FAQ

Is this an official Slack guide? No. PartnerMatch is independent and not affiliated with Slack, and this is not an official program document. Use it to understand the shape of the work, and confirm the exact scopes, requirements, and review steps in current official documentation, which can change without notice.

Should I build a bot, a slash command, or use events? Start with the one that matches your workflow. A bot is for pushing information and interactive actions into a channel, a slash command is for user-initiated lookups and tasks, and event subscriptions are for reacting to workspace activity. Most apps begin with a single surface that fits the job and add others only when a real workflow calls for them.

How do OAuth scopes work and how many should I request? Scopes control what your app can read and do, and you should request the fewest that cover your shipped features. Map each scope to a specific feature, prefer the narrower option where one exists, and add scopes when you build the feature rather than in advance. Least privilege is easier for an admin to approve and for a reviewer to pass.

What does the review actually check? The exact criteria are the platform's to define and they change, so confirm them officially. The categories are stable: least-privilege scopes, secure OAuth and token handling, secure data handling and workspace isolation, proper secret management, behavior that matches the description, and an accurate listing. Treat those as acceptance criteria you build to, and prepare evidence, not just a working demo.

Do I need to be a partner to list in the directory? Listing typically involves program steps the platform defines and updates, so confirm the current requirements in official documentation rather than assuming. The work in this guide, fit, surface choice, scopes, build, review, and listing, applies regardless of the exact program structure on the day you start.

How is this different from listing on other marketplaces? The shape is the same across serious platforms: decide fit, build on the platform's model, request least privilege, pass a review, write a converting listing, and drive installs after launch. The specifics differ in the surfaces available, the exact scopes and requirements, and the listing format. Comparing our Shopify and HubSpot playbooks against this one shows what is common and what is platform-specific.

Further reading

• Slack API portal to create an app and see the surfaces, scopes, and settings available to developers.
• Slack Marketplace to see how listed apps are presented to teams choosing what to install.
• OWASP for the common web and API vulnerability classes a security review tests for, useful on the engineering side of preparing for review.

The short version

Building a Slack app is worth real effort when your users already work in chat and your product has a moment that belongs in the conversation, and a costly detour when that fit is missing. Pick the surface to the job: a bot for pushing information and interactive actions, a slash command for user-initiated tasks, events for reacting to activity, and ship one well before adding more. Request the narrowest OAuth scopes that cover your shipped features, because every extra permission is something an admin and a reviewer question. Build for the workspace, with tokens and data isolated per install. Treat review as acceptance criteria you build against from day one, and prepare evidence of least privilege and secure data handling rather than just a demo. Write a listing that leads with the workflow and shows the app in chat, then do the post-launch work to drive installs, because the listing is the start of the work, not the end. And because platform specifics change, confirm the exact scopes and requirements in current official documentation, since this is an independent playbook, not an official one.

If you want help deciding whether a chat app fits, choosing the surfaces, or turning a listing into adoption, a Partner Audit reviews your product, your integration surface, and your marketplace potential, then hands you a concrete plan for what to build and which ecosystems to pursue.