App Directory Partner Submission and Review Guide

Hello! We're excited you're building an app to make customers' working lives more pleasant, and more productive. Our goal with this guide is to move you through the review process as seamlessly as possible. With that in mind, please read and follow the guidance below carefully.

If you have questions, your first port of call is your Partner Engineer. For issues or questions related to the submission or review process, you can reach out to us at feedback@slack.com or by using the @app-directory-team usergroup if a Slack Connect channel is set up with the Slack team.

Preparing for submission from Day One

Read through our App Directory guidelines and checklist and make sure you understand them. This contains important information about our requirements for listing in the App Directory, including how to build your app to meet those guidelines.

You can find those here:

Review Timeline

With all of the above in mind, you should be prepared to submit your app for review well in advance of any planned launches, building time in for resolving any feedback shared during the review process.

If your app is brand new to the App Directory, particularly if you are a feature launch/beta partner, please plan to submit your app at least 3 weeks before launch. If you are submitting updates to an existing app, please plan to submit your app 2 weeks before launch.

If there are any delays in your planned submission date, please let us know by mentioning your Partner Engineer and the App Directory team in Slack.

Some things to consider while building

1) Scopes and tokens

When building, consider which scopes you'll be using and wherever possible, use the least permissive and smallest number of scopes. Prioritize using the bot token over the user token as much as possible, since this will preserve functionality for your app if a Slack user is disabled, and reduces the access to the channels to which the app is added.

One consideration to keep in mind when using a bot token and associated scopes is that the bot can be added to channels where other users of the app might not be members. This allows flexibility for your app, but also means that you should consider how your app surfaces information to users who aren't members of a particular private channel, whether in Slack or in your associated service.

Please note, we rarely approve user token *:history scopes due to their permissive nature, so consider how you can use your bot token to provide customers with a high quality experience that also reduces the amount of access you're requesting.

2) Privacy model

Make sure you understand Slack's privacy model and how it compares to your own. Full users in Slack can access all public channels on a workspace, but can only see and access content in the private channels they've been added to. This includes Slack admins who, while they do have additional permissions in Slack, are not able to see the names or contents of private channels unless they are a member of that channel. Also, please note that guest users can only access the channels to which they've been added, including public channels.

Your app should uphold the same privacy model β€” where users are only able to access the information that they have access to in Slack β€” throughout the interactions with your app in Slack and in your own service.

Also consider carefully how your app might work in a Slack Connect channel. When an app is added to a Slack Connect channel, there will be users from another Slack workspace who will be able to see messages and features from that app. Make sure that you are checking for 'unknown' users before your app shares or allows access to information that shouldn't be visible to those 'unknown' users from another workspace.

Before submitting your app

Please make sure that you've completed testing and fully QA'd your app before submitting as this reduces the amount of time we run into bugs during the review process. Fully testing includes installing the app from scratch on a test Slack workspace. We often pick up errors and bugs in the review process because we're testing installations from scratch (as customers would).

If we run into any installation issues or bugs while reviewing the app, we'll return the submission, which will extend the overall review time.

Submitting your app

Testing details

Submitting with the right testing details can significantly speed up the review process and reduce any back and forth before we can start testing. As part of the review, we install the app on our own test workspace, which means we need access to any test credentials for your own service.

  • When submitting a brand new app, please make sure to add test account details for any accounts needed to connect to your service/Slack app
    • You can add those to the "Test account details for your service" in the "Help us review your app" section of the submission page.
    • If you have a complex app/web service that requires significant setup, please provide us with an account that has dummy data we can use. This helps speed up our review.
  • When submitting an update to an existing app, we need a way to fully test the version of the app that customers will use.
    • You must create a staging or development version of your app that our review team is able to access. This version of the app should include all of the changes you're submitting so that we can test them (including new functionality or additional scopes).
    • If it's not possible to provide a staging environment, please submit a short screen share of the new functionality being added, including the functionality being enabled by new scopes.
    • Please include details about the new functionality being added to your app in the "Other Notes" box of the "Help us review your app" submission section.

Video demo

  • Linking to a demo video of the app and its functionality greatly helps us with our review, particularly when that includes any required set-up and configuration. This helps us understand the desired experience and what a customer is expected to see. Please submit a link to your demo video either in the "Other Notes" section of your submission or share a link with us in your shared Slack channel.

Supporting documentation

  • Ensure that all of your supporting documentation is ready to be reviewed. This includes your app's landing page, support page and privacy policy page. If your app does not have a dedicated landing page, you may use a Help Center article to guide customers about how to install and use your app.
  • Your landing page should provide customers with clear information about what your service does, how that relates to the functionality of your Slack app, and how to install and use it.
  • If your landing page is not live at the point of submission, you should make a password-protected version available to us for review. If absolutely needed, we can review a PDF copy of your planned landing page.

Scopes reasons

  • When you include reasons for the scopes you're requesting (on the OAuth and Permissions page), please provide us with clear details about which part of your app's functionality is being powered by that particular scope. If it's not clear in the submission why you're requesting a particular scope, that can further delay the review.

When you have submitted, please let your BD/PE partner know and share any upcoming deadlines so that they can share the details with the App Directory review team.