Knock implementation guide

The first thing you’ll need to do in order to send notifications through Knock is to set up the downstream providers that deliver your messages. In Knock, we refer to these services as Channels.

Channels are configured under the Integrations tab in your Knock dashboard. You can see a full list of supported channel types and providers here.

In addition to first-party integrations with message delivery platforms, Knock also offers convenient connections to customer data platforms (CDPs) and reverse ETL providers to bring your data into Knock (Sources).

You’ll want to configure your channels prior to building any workflows so that you can set the correct delivery methods for each of your notifications.

Next, you’ll start building your Workflows. Workflows in Knock serve as containers for all of the logic and message templates associated with a given notification in your system. When you’re ready to start sending notifications, you’ll do so by triggering these workflows.

Knock’s environment model means that you’ll be creating all of your workflows and other dashboard resources in your Development environment, where you’ll commit and then promote changes to higher environments (like Production). Read more here.

You can assign one or more categories to your workflows. These can be used to power recipient preferences (which we will cover in more detail below).

Workflows are constructed from a trigger step, channel steps, and optional function steps. To learn more about creating the messages that are delivered by your workflows, you’ll want to become familiar with the building blocks of your notifications content:

• Message template editor. The message template editor is where you’ll build the content of your notifications. You can use Variables to inject dynamic content at runtime.
• Partials. Partials are content blocks that you can reuse across multiple templates.
• Layouts. Layouts are the "frame" of your email notifications, where you define shared structure and styles.
• Translations. Send message content in a user's preferred language with translations.

Workflows and their building blocks can be created in your Knock dashboard or programmatically with our Management API.

Once you’ve configured the logic of the notifications that you’d like to send, you’ll need to give Knock the necessary data about your users in order to deliver those notifications.

The User object in Knock has a number of (optional) reserved attributes like name, email, and phone_number, but it can also store any number of custom properties which can be used in the logic and templates of your workflow; for example, you might want to deliver different messages based on a user’s role. These attributes can be updated at any time with subsequent upserts.

We offer a variety of ways to identify your users to Knock, so you’ll want to look over our guide on identifying recipients before you solidify your migration plan. If you’re planning to send notifications to push or chat channels, you’ll also need to review our guide on setting channel data to ensure that we can deliver your messages to the right place.

Remember, the Knock environment model means that you’ll need to identify production users directly into your Knock Production environment.

After you’ve planned the migration of users into Knock, you may need to consider advanced use cases for non-user recipients (like a public Slack channel) or a resource in your system (like an order that has been placed) that doesn’t fit neatly under the concept of a “user.” In Knock, these resources can be modeled as Objects.

Subscriptions are an extension of objects and express the relationship between a recipient (the subscriber) and an object. When you trigger a notification to an object recipient, Knock will also fan out individual workflow runs to any recipients that are subscribed to the object. This is especially useful for examples like the order placement use case mentioned above: you can trigger an “order updates” workflow with an object that represents the order as the recipient, and we’ll notify any subscribed Users about the change without you needing to resolve the list of recipients in your system.

If your notifications should be scoped to a particular workspace or organization, you’ll need to implement Tenants in your Knock integration. A tenant can be applied as context to a workflow trigger in order to apply per-tenant branding, per-tenant preferences, and scope in-app feed messages to particular tenants.

Once your recipients (both users and objects) and tenants have been migrated to Knock, you’ll want to consider delivery preferences for your notifications to give your users control of where and when they receive updates from your product. For more information on building a preference center in your app, check out the section on Completing your client-side integration below.

Knock’s powerful Preferences API allows your users to opt out of notifications based on the notification’s delivery channel_type, the category of the notification, the specific notification workflow, or a combination of these properties. You can also extend these preferences to be tenant-specific or to evaluate conditionally at runtime.

You can set environment-level default preferences (for example, maybe a given workflow should require a user to manually opt in to receive those notifications) as well as tenant-specific default preferences that will be overridden by a recipient’s individual preferences.

Finally, for any notifications that you’ll send on a recurring basis or reminders that should be sent at a specific future date, our Schedules feature should be considered before you’re ready to finalize your integration.

Schedules can be set, updated, and deleted via API. Although they are recipient-specific, you can create a schedule for up to 100 recipients at a time.