Go to Slack

Interaction guidelines for Slack apps

The rundown
Read this if:You're still experimenting, prototyping, and exploring.
Read next:Designing a great app experience

You've storyboarded your app, given thought to the calibre of your communication, and mapped a trail through a myriad of Slack APIs.

When you start putting all of this together, it's helpful to consider some evergreen tips that will keep interactions with your app pleasant and productive. In this doc, we've collated some basic interaction guidelines for apps.


Being considerate with messaging

Messages that alert users can be incredibly useful. Many Slack apps exist primarily to pipe notifications from external services into relevant channels. Here are some Slack-specific considerations that can help ensure the messages your users want don’t turn into noise.

Be upfront during onboarding

When your app is first installed, allow the installer to easily set messaging preferences. Think about settings like the rate of messages, the channel they should be posted to, and if applicable, the type(s) of messages your app should post.

Frequency of notifications

Consider how frequently your messages are generating notifications for a user. When it makes sense, offer the user an option to get a digest of these messages rather than being alerted for individual events. This is especially important when the events are coming from an automatic source like service logs. In extreme cases, sending too many messages can get your token revoked due to rate limits.

When your app generates a lot of notifications, users will notice (and might grow annoyed). This can lead them to remove your app from a channel or even to uninstall the app from the entire workspace. One way to mitigate this is by surfacing messaging preferences often. Make it simple and intuitive for people to use your app how and when they want.

Here's an example of an app that builds a preferences link into the actual messages:

App message featuring link to change notification settings

Match message types and channels

You may already be segmenting or categorizing the types of messages that users can receive. If your service already does this, you can make the Slack notification experience even better by giving people the option to pipe different message types into different channels.

For example, an HR tool might want to pipe messages about a candidate’s background check only into #hr-team, but after an offer has been accepted and signed, maybe a #new-hires channel wants to be notified so they can celebrate.

Don’t post to a workspace’s #general channel by default. You’ll likely be unnecessarily disrupting many users and there is probably a more relevant channel for your app to post in.

Make messages that notify actionable

Some messages are best as simple text that alerts a channel that something happened in a 3rd party system. But what if that user wants to dig into your service after receiving your message? Or what if you send a system status that requires immediate action?

App message, featuring buttons for direct interaction

You can save people work by adding action elements directly into your app’s Slack messages. Buttons, select menus, and dialogs let people react in the moment and get work done faster. If your app is considerate with alerts and saves people time, they’ll likely find your app an essential part of their workday.

Your actionable messages don’t need to be complex to be helpful. Just think about what action the receiver most likely wants to take. For example, if your app sends expense approval messages, the receiver probably wants to approve or deny the expense — interactive buttons are perfect for this.

Learn more about sending messages in our messaging docs.


Sending direct messages to users

First, consider when and whether you should send direct messages (DMs) to specific users. Remember that DMs generate push notifications for mobile users and badges on desktop and mobile. These are useful but also disruptive and can be unexpected, so be cautious with your use of DMs. You should only DM a user when:

  • The user sends you a DM first.
  • The user is the only one you’re providing a service to, rather than the team.
  • Your app is sharing confidential interactions or information.

Users will assume that information shared back and forth with your app in DM is private. Be aware of any sensitive information that’s being shared, and don’t surprise users by announcing results of DM conversations in channel without letting them know first.

Need to send a DM? Read our guide to finding conversations via the Web API and then about sending messages.


Responding to users in channel

Whatever you post in channel is going to be long-lived and add to the group conversation that people are reading, both in the moment and later when they may look back at what was shared.

Public and ephemeral responses

In response to a user action, an app could publish an in-channel message, or an ephemeral message. In-channel response will be visible to all channel members where the user invoked the action. Ephemeral responses will only be visible to the invoking user.

Remember that a chatty app is not necessarily a good thing, so only pick responses that are important to the entire team when posting in-channel.

If the response only needs to be displayed to the user, it’s a better idea to use an ephemeral message than it is to generate a DM.

An ephemeral message posted by an app

Read more about ephemeral messages in our Messaging docs.


Avoiding large-group mentions

There are very few cases where your app should send broad mentions like @channel, @here, or @everyone. One exception might be if your app sends a notification for immediate action when a critical system or service goes down. Even then, you should get explicit permission from the installer before your app uses one of these mentions.