Building your OAuth Slack flow and storing channel data in Knock
Once you have your Slack app configured and you've figured out which OAuth scopes it will need, you're ready to build the OAuth flow your customers will use to install your Slack app in their Slack workspace.
Here's what we'll cover in this guide.
- How to build a simple Slack OAuth in your product
- How to use the response received in that OAuth handshake to set Knock channel data
- How to decide when to set Knock channel data on
How to add a Slack OAuth flow to your product
To get the channel data required to send notifications to a public/private/DM channel in your customer's Slack workspace, you'll need an OAuth flow in your product that your customer uses to authenticate into Slack and give you an access token you'll use to send Slack notifications to your users.
The best place to start is with Slack's Installing with OAuth documentation.
Once you're receiving Slack OAuth callbacks on the endpoint you've set up, you're ready to store that response as channel data in Knock.
How to set Slack channel data in Knock
When you receive an OAuth callback from Slack, whether it contains an
incoming_webhook_url or an
access_token, you'll need to set it as channel data on either a
user or an
object in Knock. We cover how to decide which to use below in the "setting channel data: users v. objects" section of this document.
Here's an example of setting channel data on an
object in Knock.
Channel data requirements
Here's an overview of the data requirements for setting recipient channel data for either an incoming webhook or an access token Slack connection. Both will need to live under the
SlackConnection with incoming webhook url
SlackConnection with an access token
Setting channel data: users vs. objects
Depending on the Slack integration you build into your product, you’ll either store the connection data you receive from Slack on a
user or an
object in Knock.
If your integration involves a user opting in to receive DMs from your Slack bot about information pertaining to them, you’ll likely be storing the channel data on that user in Knock. Then when you want to notify this user, you include the user as a recipient in a Knock workflow trigger.
If your integration involves a customer connecting a non-user resource in their product to a Slack channel, such as a project or a page, you’ll want to store that channel data on an
object in Knock, as it’s not specific to any single user.
Here's a real-life example of how
objects would be used in a product you may be familiar with: Notion. In Notion you can connect a Notion page to a Slack channel of your choosing. If we were to power this with Knock, when a user completed the Slack OAuth flow for that Notion page, we’d store the connection data on the Knock
object that maps to that Notion page. Then when something happens on that page that the connected Slack channel should be notified about, we include the notion page
object as a recipient on the workflow trigger.
You can learn more about the Knock object model and see an example how to use it to power Slack notifications in our Objects concept guide.