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
You will need to create a RudderStack destination for each Knock environment that you want to receive events from RudderStack.
- In your RudderStack workspace, navigate to the "Destinations" page and click "New destination." Search for and select "Webhook"
- Give the destination a name (e.g. "Knock <environment name>") and click "Continue"
- Optionally, choose the sources you want to route into this destination. Then, click "Continue"
- 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"
- 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.
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.
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.
Inline identify users in a RudderStack event
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.