Email settings and overrides
Learn more about how to configure your email channels in Knock.
Knock email channel configurations support a number of settings. These include email-specific fields (such as cc
, bcc
, and reply-to
) as well as JSON overrides to be passed in API calls to the configured provider's API endpoints.
When you configure a setting in a channel's configuration, it will be used on all instances of that channel across all workflows.
Configuring email settings#
You can override email settings on a per-channel basis, or on a per-template basis.
- At the channel level. The
to
,cc
,bcc
, andreply-to
fields can be found in the "Overrides" section of the channel's "Settings" tab. - At the template level. The email settings fields can be found at the top of the email template editor.
All email configuration fields support Liquid usage. You will be able to use any variables available in your workflow trigger payloads, as well as system variables such as the current workflow, activities, and any other variables you have access to when building templates.
As an example, if you wanted to conditionally change the "From name" on an email depending on whether one is configured on the actor that triggered the notification, you'd use the following liquid in the "From name" field of your email configuration.
to
address
Overriding the default #By default, Knock will send your emails to the email
property stored on the recipient
for the workflow run. If you need to override this, you can do so by setting the to
field in your email configuration either at the channel or the template level.
As an example, if you wanted to send all emails to a single address, you could set the to
field at the channel level to either a static value (like hello@example.com
) or a dynamic value (like {{ data.email_to_override }}
).
to
addresses
Using multiple #It's possible to set multiple to
addresses via an override. However, because Knock is designed to process a unique workflow run for each recipient
in your workflow trigger, this approach comes with some caveats and limitations:
- You must always provide at least one
recipient
on your workflow trigger. - Although you may override the
to
email addresses to send an email to more than one address in a given workflow run, that run will reference only the originalrecipient
's properties and notification preferences. - Delivery and engagement metrics will also be associated with the original
recipient
, because all of the delivered emails will be related to a singleMessage
record in Knock. This means that you won't be able to track per-recipient metrics for the list of email addresses in your override; they'll all be tracked by the workflowrecipient
. - Knock does not currently support a comma-separated list of
to
addresses in the same way as we do forcc
andbcc
addresses (see section below). This means that you will need to provide a JSON payload override in your workflow step's configuration in order to format theto
list according to your provider's API requirements. Please reach out to our support team if you need help with this.
cc
and bcc
addresses
Setting #The cc
and bcc
fields can be used to support a single or multiple addresses. In order to use several addresses on any of these fields, make sure to separate them with a comma.
Provider JSON overrides#
Sometimes you may want to customize the API call Knock sends to your email provider.
A good example of this is passing custom arguments as part of the API payload.
Take an example where we're using SendGrid as our email provider. SendGrid allows sending custom arguments under the
custom_args
key of the JSON payload of their API. By default, Knock sends some arguments using that key, such
the Knock message id. If you want to add more arguments, you can check the following image on how to add them as
JSON overrides:

In this example, we want to add two arguments to the custom_args
attribute of the
API call we send to SendGrid. In this case, the first argument will be hardcoded,
and the second argument's value will be the value of workflow_variable
, which we
expect to be passed in the payload of the workflow trigger call.