How to integrate RudderStack to Knock

Video walkthrough

Getting started

Knock is a RudderStack Destination, which means you can use events coming through RudderStack to power actions in Knock, such as triggering a workflow.

You can start routing your RudderStack events to Knock by creating a source of type "RudderStack" in the dashboard. From here, you'll be taken to the environment configuration page for the source which will give you unique URLs for each environment you have configured in Knock.

You'll copy this URL and use it to let RudderStack know where to send events.

Configuring RudderStack

Use webhooks to connect to Knock. Knock does not have a first-party integration with RudderStack, so you will not find us in the list of destinations. Instead, you'll configure the connection to Knock via a webhook destination as described below.

You will need to create a RudderStack destination for each Knock environment that you want to receive events from RudderStack.

  1. In your RudderStack workspace, navigate to the "Destinations" page and click "New destination." Search for and select "Webhook"
  2. Give the destination a name (e.g. "Knock <environment name>") and click "Continue"
  3. Optionally, choose the sources you want to route into this destination. Then, click "Continue"
  4. Paste the URL from the Knock dashboard for the Knock environment you want to receive events from RudderStack. Make sure the "URL Method" selected is POST. No other headers or settings are required. Click "Continue"
  5. Transformations may be configured as needed, but are typically not required. Click "Continue" to finalize the RudderStack destination

Viewing RudderStack track events in Knock

Once your RudderStack destination is set up all events you trigger from the RudderStack source will be forwarded to Knock. Unique events will appear in your list of events under the Source so that you can set up actions to trigger your workflows.

From the source environment configuration page click the "View in environment" button on one of the source environments. You'll be taken to the RudderStack source in the environment you selected and you should see events sent. If you don't, try clicking the refresh button on the top of the list to refetch any incoming events.

Connecting a track event to an action

You can add a track event as a trigger to your workflow directly from the workflow builder. Click on the workflow's trigger step and change the type from "API" to "Event." Then you'll be able to select the event and map its properties into the data the workflow needs.

Using properties. To use any of the properties fields, you can access them with dot-syntax by prefixing them with data.. For example, if your payload looks like this:
and you wanted the commenter from the action to appear as the Actor in the workflow, then in the Actor field you would write data.commenter.id to supply their ID as the actor.

Committing the event action configuration

Event action configurations are stored in the commit history, just like workflows and email layouts. Once you're happy with the mapping, you can save it and commit it to your development environment using the same commit button as your workflow. When you're ready you can publish this event action configuration to your other environments from the commit page.

Committing actions that trigger workflows. Keep in mind that when you commit your workflows to development and publish them to other environments, you'll have to do the same with your actions to make them trigger that workflow in those environments as well.

Disabling an action

Actions are automatically enabled when you create them. If you want to stop an event from triggering an action, you can go to the action page and toggle its status to "Inactive." Keep in mind that this will disable that action for the current environment only. When you're ready to trigger the action again, you can set it back to "Active."

Enabling Identify Events

When RudderStack sends identify events, Knock will create and update user information accordingly. Knock will correctly map the id, email, phone, avatar, name, and any other custom properties over.

To enable handling of identify events, open the settings for the source in the environment. You can then enable or disable handling identify events accordingly.

A screenshot of how to toggle Knock handling RudderStack identify calls

Inline identify users in a RudderStack event

☝️
Note: Inline identification is not supported by our workflow test runner, which can only trigger test runs for existing users. To test inline identification with a source event, you should send a test event from RudderStack.

In cases where you send a RudderStack event to Knock with recipients that may not yet have been identified into our system, it's good practice to inline identify your users. By inline identifying your users within your RudderStack events, you ensure that those users are identified in Knock when your event triggers a workflow.

As an example, take the user-signed-up event below. We're currently mapping the properties.recipients field to the recipients field of our workflow in Knock. If we send this event to Knock before the user with id sam10 has been identified, the user will not be notified.

To ensure that the user is notified, we'd change the id reference in recipients to a complete user object, as in the example below. This way Knock has all the information it needs to identify the user during workflow runtime.

You can learn more about inline identification in our guide on identifying recipients.

Video walkthrough

This video is Segment-specific, but you can apply any of the portions within the Knock dashboard to RudderStack as well.