At a time when businesses are increasingly relying on Slack for day-to-day operations, the Slack App Directory is thriving. These days, there are Slack apps for everything: from polls to team recognition, to daily standups, to promoting inclusive language. There has never been a better time to be a Slack user.
Likewise, there has never been a better time to create a Slack app!
But it’s not all sunshine and roses. I’ve been through the Slack app process twice, first with UPPIT and now with AllyBot. Building a Slack app is fun and Slack is always improving the developer experience. But, there are a few gotchas that have cost me a lot of time during the review process.
Here are 5 reasons why Slack will reject your bot, and what you can do about it.
Do yourself a favor and use bolt.js. This one might be obvious, but it certainly wasn’t to me when I built UPPIT. Don’t get me wrong, you can build a basic Slack app with the Slack web API and your backend framework of choice; this is what I did with UPPIT.
But when you go to submit your app to the Slack App Directory, you will soon realize there are a bunch of security things you probably didn’t consider. OAuth and token management, and verifying requests from Slack and the ones I’ve failed with in the past. Both these topics deserve an article, but the takeaway is that bolt.js handles a lot of this stuff for you. It provides sensible interfaces and callbacks for the things you need to customize. It also provides simple wrappers for the Slack web API out of the box. bolt.js an obvious choice that allows you to focus on building your app.
I estimate 20% of the time I spent on UPPIT was on these auxiliary tasks, whereas when I used bolt.js for AllyBot, it was more like 5%.
Don’t reinvent the wheel - use bolt.js!
2. No customer support or poor branding
When you’re in the trenches building your app, it’s easy to forget that you need to market the thing! Slack requires a bunch of items on this front. Let’s go through some of the ways you can succeed on this front.
Support email address and contact form
You need an email address for support and a support page on your website. For email, I use Zoho. It’s free, and I’ve set up email@example.com, and a “catch-all” alias that points to firstname.lastname@example.org. This means I can list my app’s support contact as something like email@example.com and I’ll receive any emails sent there at firstname.lastname@example.org.
Add to Slack button
Make sure your website has an Add to Slack button. If you’re using bolt.js, link this button to https://<your-app.com>/slack/install. Redirect the user to an “Install Successful” page once they’ve successfully installed your app (Slack requires this).
Slack has a bunch of resources on this topic, but the bottom line is this: keep your branding consistent and don’t conflict with Slack’s branding. Simple!
3. Bad use of the App Home
Utilizing the App Home in Slack can be confusing, but this is a must-do. Slack has a whole article on this, but here are some essentials.
Send the user who installed your app an intro message
When a user installs your app, you need to send them a message that explains to them how to get started. Here is AllyBot’s welcome message:
Of course, make sure you only send this once.
Respond to app_home_opened event
When a user other than the user that installed your app opens your apps App Home tab, you need to greet them as well! Again, this should only be a once-off. I have a flag for app_home_opened in the user table of the database, set to false. When the user first opens the App Home tab, this flag flips to true so I know never to send the message to the user again. The message can be like the first one, for example, this is how AllyBot.io responds to app_home_opened:
Note that you will need to request the
im:write scope to start chats with users.
4. Not giving good reasons for your requested OAuth scopes
This is a common reason Slack apps get held up in the review process. You should take the time to consider if your app needs all the scopes you are requesting. Slack will reject anything that seems like a “nice to have”.
Give genuine reasons about why you need a certain scope. And be transparent. If you are capturing user emails (with the
users:read.email scope), then say so.
5. Poor error handling
During the review process, Slack will try and break your app. But don’t see this as a negative; we should be super grateful to get free QA testing (thanks Slack)! Using bolt.js will help you here. But, if your Slack app uses slash commands, or “actions” (buttons, etc.), think carefully about where your app could fail.
Make sure to send the user a message when errors occur. An “ephemeral” message is a good way to do this; an inline, private message to the user interacting with your app. Something as simple as “Oops, something went wrong 😢” is a good start, but always try to give direction to the user.
Ask me anything
Have I missed something? Need something clarified? Hit me up on Twitter @tom__quirk.