SlackKit overview

SlackKit is Knock's collection of components, hooks, and APIs to quickly set up Slack in your application for your users to integrate with their own Slack workspaces.

Instead of handling the OAuth handshake, access token grants, and channel connection yourself, you can use our pre-built components or build your own components on top of our API.

SlackKit is designed around the most common use case for a Slack app integration: sending notifications to the channel(s) that your customer selects from their Slack workspace. You can find more information on augmenting your Slack integration to send direct messages to individual user recipients here.

Key concepts

SlackKit connects multiple concepts in Knock to make it easier for users to create a Slack integration. There are two key concepts you'll see throughout the following docs that are foundational to how SlackKit works, but might not be used in every implementation of Knock: tenants and objects.

About tenants

Tenants in Knock are meant to represent segments of your user base. You might call these "accounts," "organizations," "workspaces," or something similar. In a standard SlackKit implementation, you'll store a Slack workspace's access_token on a corresponding tenant in Knock.

If you already use Knock's tenant concept to power other 'account-based' features, you likely create tenants in Knock when an account or organization is created in your application. If you don't already use tenants in Knock, SlackKit can create tenants for you on the fly if they don't already exist.

💡
Note: Our best-practice recommendation is that tenants in Knock should map one-to-one to whatever abstraction you use to model accounts, organizations, or workspaces. You can think of tenants as the top-level container within your data model that you use to power multi-tenancy in your application.

About objects

Objects in Knock are flexible abstractions meant to map to a resource in your system. Each individual object in Knock exists within a collection and requires an id unique to that collection.

In the context of SlackKit, objects serve two purposes. First, they store the Slack channel or channels you want to notify. Second, they act as the recipient of the workflow that sends a message to Slack.

💡
Note: You can think of collections as the different tables within your database that represent resources in your application. Objects are the rows within those tables.

Example

Let's say we're building an example source control application like GitHub, where teams can collaborate and share code repositories. In this context, each GitHub organization would map to a tenant in Knock, and each repository would become an object inside of a repositories collection.

If we want to be notified in Slack each time an issue is opened against a repository, we would store a Slack channel on each repository object and then trigger a new-issue workflow. Knock will use the data stored on the object and tenant to route a message to the correct Slack channel:

Next steps

In this section, you'll learn how to:

  1. Set up your SlackBot
  2. Grant your users access to the Knock data they need with signed JWT tokens
  3. Add SlackKit UI
  4. Trigger notifications using tenants

We also have two example apps for you to get the feel of how to integrate Slack and Knock with SlackKit:

←Example use cases
Setup→