Being a good citizen inside Slack

Now you've storyboarded out your interactions, given thought to your messages' format and content, and the voice and tone of your app; you're in great shape. These last few things can take your app from being good to delightful, by being considerate.

Considerate notifications

Notifications can be incredibly useful; many Slack apps exist primarily to pipe notifications into relevant channels. Presumably, your users have opted-in to the notifications they receive somewhere in your service. Here are some Slack-specific notes that can help ensure that the notifications your users want don't turn into noise:


What's the velocity of events that generate notifications for your user? When applicable, offer the user an option to get a digest of the notifications rather than being alerted for individual events. This is especially important when the notifications are coming from an automatic source like server logs. In extreme cases, sending too many notifications can get your token revoked due to rate limits.

Match notification types and channels

You may already be segmenting or categorizing the types of notifications 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 notification types into different channels.

For example, an HR tool might want to pipe notifications 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.

Considerate DMs

First, consider when and whether you should DM specific users. Remember that DMs generate push notifications for mobile users and badges on desktop and mobile; if users have the setting turned on, they'll also receive an email. These are useful but also disruptive— so be judicious with your use of DMs. You should use a DM when:

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

It's worth a note that users may assume that information that's shared back and forth with your bot 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.

Considerate responses 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

By default, the response messages sent to commands will only be visible to the user that issued the command (we call these "ephemeral" messages). However, if you would like the response to be visible to all channel members where the user typed the command, you can add a response_type of in_channel to the JSON response:

    "response_type": "in_channel",
      "text": "It's 80 degrees right now.",
      "attachments": [
            "text":"Partly cloudy today and tomorrow"

Remember that a chatty app is not necessarily a good thing so only pick responses that are important to the entire workspace for this type of response. If the response only needs to be displayed to the user, it's a way better idea to use "response_type": "ephemeral" than it is to generate a DM.

Taskbot ephemerals message

Clean up after yourself

This has been covered in earlier sections on message lifecycle, but it bears repeating. After your message has "expired" or changed state, remember to clean up the message for future legibility and use. Update your attachments to reflect what people will need to know about it when they read it a day, a week, or a month later.

When in doubt, give your users more control. The more granular you let people get with opting in to notifications, the more likely they are to value the ones they do receive.

Was this page helpful?