Changelog

Today we're excited to announce a new design for our commits page.

Teams operating customer engagement at scale know the difficulty of managing multiple changes across several teams and channels. With all of the moving parts, it's easy to lose track of what's been changed and when.

Knock enables teams to collaborate effectively with a powerful commit and environment model. But we recently identified a need to enhance the commits page UI to be even more useful. That's why we've redesigned our commits page with a focus on clarity and usability, making it easier for growing teams to manage changes to their notifications.

The new design is available today to all users under the "Commits" tab in the sidebar.

Fixes and improvements

• 👀 [Dashboard] We added support for the "markdown" Liquid filter to allow MarkDown input -> HTML conversion
• 👀 [Dashboard] Rolled out trigger event improvements
• 🐛 [Dashboard] We fixed an issue with Menu Buttons firing multiple times
• 🐛 [Dashboard] We deployed a fix for an email template rendering issue
• 🐛 [SDK] We addressed an issue in the Go SDK where some user properties were incorrectly marked as required

React 19 support in our JavaScript SDKs

Today we're releasing support for React 19 in our web JavaScript SDKs. This will enable projects with React 19 as a dependency to use our SDKs without any additional configuration. Projects using React 18 or below can safely upgrade to the latest SDK versions without any code changes, as this update maintains full backwards compatibility. All code changes can be found in the GitHub pull request here.

To upgrade, set the package versions in your package.json to the latest version listed below, then reinstall.

Here are the latest versions of our SDKs:

• @knocklabs/client: v0.12.0
• @knocklabs/react: v0.6.0
• @knocklabs/react-core: v0.5.0

With these updates, our web SDKs now support React versions 16, 17, 18, and 19.

A note on the react-native and expo packages:

The react-native and expo packages do not yet support React 19.

React 19 recently became available on React Native, however, some of the internal dependencies need time to catch up and support these changes before we can update our own packages.

Since the underlying dependency on @knocklabs/client was updated, we released a new version for these packages as well.

• @knocklabs/react-native: v0.6.0
• @knocklabs/expo: v0.3.0

React 19 support in our Telegraph components

In addition to the JavaScript SDKs, we've also updated our Telegraph components to support React 19. As a dependency of our JavaScript SDKs, this means that you can now use our in-app notification components and hooks with React 19 without any additional configuration.

You can read more about using our React components to build in-app notifications in the docs here.

Fixes and improvements

• 🐛 [Dashboard] We fixed a bug where users were able to create variables without setting a value

Email-based user ID resolution for Slack

Today we’re introducing email-based user ID resolution for Slack, simplifying the steps needed to send direct messages via Slack to your Knock users.

Previously, if you wanted to send a direct message via Slack to one of your users, you needed to update your Knock user’s channel data to include their Slack user ID. This ID is typically found by making a request to the users.lookupByEmail endpoint of the Slack API using your Knock user’s email address.

Now, Knock can automatically make this API request on your behalf before sending a message. When the request succeeds, Knock will automatically add the Slack user ID to the user’s channel data.

You can read more about enabling email-based user ID resolution for Slack in our documentation.

• 👀 [Dashboard] We made it possible to see who created a workflow, in addition to who last edited a workflow.
• 🐛 [Notification engine] We fixed a bug in which temporary failures from Mailgun were treated as undelivered.
• 🐛 [Dashboard] We fixed a bug in which a cloned workflow would default to the inactive state.
• 👀 [SDK] We updated our SDKs to include ending_at for scheduled workflows.

Filter messages by workflow run ID

Today we're introducing the ability to filter for messages by a workflow run ID or a workflow recipient run ID.

Before, if you wanted to find all of the messages produced for a single workflow trigger call you needed to attach your own identifier to your messages and use our trigger data filtering. Now, with our new filtering capabilities, you can filter for messages by the workflow run ID returned from a trigger request, or an individual workflow recipient run ID.

We've introduced these new filters into the messages API, and also to the dashboard, making it easier than ever to track down specific messages produced from a single workflow run, or for multiple workflow runs from a single trigger request.

Fixes and improvements

• 🐛 [Notification engine] We fixed an issue with our SMTP sender where including a from name could cause some email providers to fail.
• 👀 [Dashboard] We added support for better surfacing inline errors in our code editor for Liquid, JSON, and Markdown.
• 👀 [Dashboard] We now show the total number of members in a workspace in the members list.
• 🐛 [Dashboard] We fixed an issue with our fetch step where in certain cases it could fail to send a test with a hard crash.
• 🐛 [Dashboard] We added support for being able to use message conditions on push notification steps.
• 🐛 [Dashboard] We fixed a small bug where descriptions longer than 255 characters for variables would fail to save.
• 🐛 [Dashboard] We fixed a minor issue with our commit log viewer where long lines were not wrapping.

Per-recipient workflow trigger data

Today we're releasing an extension to our workflow trigger API: the ability to supply per-recipient trigger data. Previously, the data field supplied to your workflow trigger was shared across all recipients, meaning that if you wanted to supply recipient-specific data, you had to do so by either triggering a workflow per-recipient, or by stuffing data onto the user's profile.

Now, with the introduction of per-recipient trigger data, you can supply recipient-specific trigger data for up to 1000 recipients at a time via the workflow trigger API. The per-recipient trigger data will be merged onto the base workflow trigger data, making it easy to still supply shared data to all recipients of your workflow while providing anything recipient-specific.

Here's an example, where we're supplying a recipient-specific dashboard URL to the workflow. In this example, when the workflow runs for esattler, it will merge the contents of their trigger data onto the base data, so the dashboard_url will be https://dashboard.jurassic.park/esattler.

{
  "data": {
    "dashboard_url": "https://dashboard.jurassic.park",
    "alert_type": "dinos-roaming",
    "alert_id": "1234567890"
  },
  "recipients": [
    {
      "id": "esattler",
      "$trigger_data": {
        "dashboard_url": "https://dashboard.jurassic.park/esattler"
      }
    }
  ]
}

Fixes and improvements

• 🐛 [API] We fixed an issue where the user deletion API could sometimes respond with an inconsistent status code.
• 🐛 [SDK] We fixed an issue where the Python SDK would not correctly handle JSON errors from particular versions of the requests library.

Today we're releasing TeamsKit, a suite of embeddable UIs and APIs that lets you connect your product to customers' Teams instances and send notifications to where they work.

Behind the scenes, TeamsKit:

• manages your OAuth connection and tokens.
• helps your customers select which channels they will receive notifications in.
• integrates seamlessly with the rest of Knock, so you can easily send notifications to Teams alongside any other channel.

Shipping a Teams integration has never been easier.

Read the full announcement ->

Schedule workflows until a specific date

As a nice quality of life improvement, we've added a new ending_at field to Schedules. The ending at field allows you to schedule a workflow to repeat for a recipient until a specific date, making it easy to build schedules that run for a limited time.

You can read more about scheduling workflows with an ending date in our documentation.

Fixes and improvements

• 👀 [Dashboard] We added support for setting an empty layout for email templates in a workflow.
• 👀 [mAPI] We added support for a null layout_key for email templates in a workflow.
• 🐛 [Dashboard] We fixed an issue where previewing an email template with an invalid set of JSON overrides would fail.
• 🐛 [Dashboard] We fixed an issue where changing a step title or description would not save correctly when typing quickly.
• 🐛 [Dashboard] We fixed an issue where partials could not be used when they use system key names like primary-button.

Programmatically preview workflow templates

We've added a new endpoint to the Knock Management API to preview workflow templates. This is useful if you're looking to integrate Knock into your own application and need a way to preview templates with user supplied data, like when building a template customization experience.

To use the preview endpoint, you pass it a channel step on a workflow, and provide the recipient, actor, tenant, and data parameters to render the template with. The API will then return a JSON object with the rendered template across all channel types, or a detailed error response if the template could not be rendered.

You can read more about the preview endpoint in our documentation.

Fixes and improvements

• 👀 [Dashboard] We added pagination to the source events list.
• 🐛 [Dashboard] We fixed an issue where the "Previous" button on user, object, and tenants lists would always return you to the first page.
• 🐛 [Dashboard] We fixed an issue where the count at the bottom of some table views would always only show the number of items returned on that page, not the total number of items.
• 🐛 [Dashboard] We fixed an issue where creating a workflow from a template with a category would fail.
• 🐛 [Notification engine] We fixed an issue where SMS links over 255 characters would not be shortened.
• 🐛 [API] We fixed an issue with paginating users, objects, and tenants with a before cursor.

SMS recipient override

Today we're announcing support for overriding the recipient of an SMS message. This is useful if you want to send an SMS to a different user than the one that triggered the workflow.

With the new SMS recipient override, you can now specify either a static or dynamic value via Liquid for the recipient of an SMS. For example, you might be sending an SMS to the user, but be sending it to the new phone number they entered and stored on the recipient profile as recipient.new_phone_number.

You can read more about SMS overrides in our documentation.

Fixes and improvements

• 👀 [Dashboard] You can now see environment.merged_latest changes in the audit logs.
• 🐛 [API] We fixed an issue where hourly schedules with an interval > 1 would be enqueued at the wrong time.
• 🐛 [Dashboard] We fixed an issue where the workflow builder would show an incorrect tooltip when adding steps.
• 🐛 [Dashboard] We fixed an issue where after adding an integration, you would need to refresh the page to see it show up in the workflow builder.
• 🐛 [SDK] You can now safely mount the <KnockProvider> in the React SDK with a null or undefined userId.

Reference dynamic object, user, and tenant data in templates

Today we're announcing support for referencing objects, users, and tenants dynamically in templates. While we've always exposed properties on the template such as the recipient, actor, and tenant, if you needed to reference other object or user data stored within your Knock environment, you had no access to that within your workflow scope.

Now, with template references, you can load arbitrary objects, users, and tenants into your template context. This allows you to reference any data stored within your Knock environment, such as a different user's profile, a tenant's settings, or an object's properties. Using template references brings access to any kind of third-party object data that you might want to store in Knock, without needing to pass it into your workflow data.

Here's an example. Let's say you're a collaboration product, and you want to show the current project's most up to date title and description in an update email for things happening on that project. With template references, you can load the project object dynamically at execution time by passing in a project_id into your workflow trigger, and then loading the project object into your template context.

{% assign project = data.project_id | object: "projects" %}

# {{ project.title }}: new updates

> {{ project.description }}

There have been {{ total_activities }} updates on this project in the last 24 hours.

This feature is available now to all Knock customers. You can read more about the feature in our template references documentation.

Fixes and improvements

• 🐛 We fixed an issue with the workflow canvas where it would no longer center correctly.
• 🐛 We fixed an issue with channel steps in the workflow builder, where it appeared you could change the selected channel in non-development environments.
• 🐛 We fixed an issue where cleaning up message history on the deletion of a user would sometimes fail.