In just a few short years, Slack has gone on to become an indispensable work tool in our always on often mobile work life. A big part of the workflow improvements they offer is the fine grained control on notifications you receive from them. Not only can you choose to be notified on email, desktop and mobile, you can also set a notification schedule and adjust interval between getting the same notification on the desktop and on your mobile.
This is a complex problem to solve engineering wise. A few years back, Slack shared the flowchart of how they decide to notify you. Let's dissect that flowchart in this article.
You can be notified for messages on the channels you are part of, unless you mute a channel.
That's the first thing Slack checks in their flowchart.
The next thing they check is if the user has enabled DnD. Users can enable it at any time or setup a schedule to toggle DnD automatically.
However, Slack also offers the sender an option to override your DnD setting, thereby resulting in the next section of the Flowchart
If you are not in DnD or if DnD was ignored by the sender, Slack checks if this message is in fact a @channel, @everyone or @here mention and if you have disabled notifications for those (for this channel).
This is checked in the next part of the flowchart
Notice the part about this message being part of a thread? Slack let's you set a global preference for notifying you of replies to threads
However, it's interesting to that even if this setting is turned on but you have disabled notifications entirely for the channel, you won't get notified. See this part of the Flowchart (the leftmost branch leads you to the big RED NO).
Before we go on any further, let us talk about Slacks ability to let you setup a different preference for mobile notifications. They allow you to do this globally, as well as per channel. It looks something like this
Assuming that the notification candidate has made it so far (and so have you!), Slack checks for mobile specific notification preference for this channel. If none has been setup, they check if you have a preference globally.
If you have chosen to not be notified of anything, it's a straight line to the big RED NO. However, if you have chosen to be notified, based on your preferences, you may lead down to the big GREEN YES. However, you may reach here on the desktop or on the mobile. In the Flowchart they talk about checking for "past mobile push timing threshold" but I wasn't able to find this as an option in their UI. Perhaps this is something check for in their backend without it being a user adjustable property.
As you can see, building a sophisticated notification system is fairly complex. It doesn't have to be. MagicBell can take care of all of this for you while you focus on the core functionality of your product.
Here are a few related articles!
This is the first part in a series of articles in which we'll design and implement a Notification System from scratch. We'll do this in Ruby on Rails, but the concepts are widely applicable to any web application framework. This part focus on the database design.