For many organizations, Slack is the software of choice for business communication. Slack’s ubiquity in modern companies makes it one of the first notification integrations a SaaS company might want to build, possibly after email and mobile push notifications.
In our experience, Slack notifications are a great way to reach business users (as Slack is mostly used in a business context) with time-sensitive alerts or action items while they’re at work. Because the users are already in work mode, Slack notifications are suitable for anything from collaboration on documents and spreadsheets to workflows like approval requests or data access permissions. Slack is less suited for notifications outside of a work context or out of working hours.
To be able to send messages in Slack, a software system must integrate with
Here’s another example of a Slack integration from
Many organizations don’t quite know what to expect when building an integration for sending messages from their SaaS product to a Slack channel or a direct message. In this post, we offer details for developers who are planning to build a Slack integration for their product.
From a technical perspective, Slack offers a fairly conventional HTTP REST API, which will be straightforward to understand for developers who deal with web systems. The functionality made available through the API is extensive, and there are complex parts to it, but most Slack integrations for SaaS will likely only need to send messages.
Messages are the core of Slack’s functionality, but we cover other actions that your app might need to take in Slack below.
For sending messages, the
The main way to send a message is the POST chat.postMessage endpoint, but it’s also possible to use other endpoints with slightly different functionality: the
Beyond sending messages, other functionality that you can implement with Slack’s API includes:
Many software teams choose to develop all functionality relating to Slack or another messaging service either in a dedicated microservice (if you use microservice architecture) or at least in a separate section of your monolithic app.
The reason to do this is to avoid tightly coupling the way you think about notifications to Slack’s API — doing so could cause issues when the time comes to add support for other messaging APIs. Another reason to use a separate service or namespace for the Slack integration is to implement message retries and other reliability-focused tweaks. Such code would be too complex to include inside your business logic.
In our experience, there are a few points that developers might not be thinking about when building a Slack integration, and we encourage you to consider them:
When we advise our customers about Slack integrations, most of our advice centers less on the implementation details and more on the product functionality and customer experience side. We see teams who are building Slack notification functionality for their SaaS focus too much on sending Slack messages and not enough on the value those notifications deliver to their users.
In this section, we offer a few recommendations on designing a helpful Slack notification experience.
Something that we find useful for many customers is keeping track of Slack statuses (the little “active” and ”away” indicators you see on people’s profiles). Consider whether you even want to send Slack notifications if someone is marked as being away in Slack — they might not be on their computer, or they might have intentionally changed their status. Is the notification you’re sending in Slack going to be actionable for someone on their phone? For many SaaS applications, the answer is no.
Our recommendation on handling status is to send Slack notifications when the user is active in Slack, and when they are not active, using a different channel like email or mobile push.
In a SaaS product, it’s very unlikely that you’ll need just one type of Slack message. An app can require tens or hundreds of different notifications to be sent via Slack — and managing such large numbers of messages in your codebase can get tricky.
We recommend using templates instead of hard-coding messages in your application. It’s likely that your message templates will change over time, and you might want to add new notification types as you develop your product. By relying more on templates you can simplify the code review process — it’s easier for a peer to review a template change in a separate file than to jump between templates and code.
Another recommendation is to make templates editable outside of the code review process. This capability will enable colleagues outside of the development team to change and tweak notification templates themselves without the need to commit directly to the codebase.
Are you going to only offer notifications in one language, or multiple? If you’re offering multiple languages, how does a user configure their preferences? You might want to add functionality within the Slack app that allows users to configure their language settings, or have a section within your web app (outside of Slack) with notification preferences. In any case, you need to store language preferences for each user and, eventually, have a good way to store translated versions of notification text as well.
We also recommend that you consider the translation workflow for notification text — the translators will likely not be able to navigate your codebase due to limited permissions or lack of technical context. Making it straightforward for the translators to work with your notification text will make it faster to implement new notification languages.
In this article, we’ve covered our recommendations for building a successful Slack integration for your SaaS product.
Prefer not to implement the integration yourself?
With Courier, sending a Slack message only requires one API call to Courier’s
If you’re interested in offloading building a strong Slack integration for your SaaS notification system,
Also published here.