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 users vs. objects

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.


🚨
Potential confusion alert. In the example above, the KNOCK_SLACK_CHANNEL_ID variable is the id of the Knock channel you've created to represent your Slack app within the Knock dashboard. You can get it by going to Integrations > Channels in the Knock dashboard and then copying the id of your Slack app channel.

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 connections key

connectionsSlackConnection[]*One or more connections to Slack

SlackConnection with incoming webhook url

incoming_webhook.urlstring*The Slack incoming webhook URL

SlackConnection with an access token

access_tokenstring*A bot access token
channel_idstring*A Slack channel ID
user_idstring*A Slack channel ID

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.

←Slack apps and scopes
Designing Slack templates→