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 triggers for 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.

Triggering workflows from received events

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 "Source 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 event 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.

Read more on configuring workflow triggers

Disabling a trigger

Triggers are automatically enabled when you create them. If you want to stop an event from triggering a workflow, you can go to the trigger page and toggle its status to "Inactive." Keep in mind that this will disable that trigger for the current environment only. When you're ready to trigger the workflow 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.