Changelog

Today we're shipping the ability to use AI to generate workflow trigger data schemas, making it effortless to get started with verifying the data being passed to your Knock workflow trigger.

Last year we shipped our workflow trigger data schema validation, which allows you to use a JSON schema to describe the data that's expected as part of your workflow trigger. However, getting started here required you to write out a full JSON schema from scratch.

Now, using AI, you can click the "Generate schema" button to automatically generate a trigger data JSON schema from data available to your workflow. It's like magic.

Fixes and improvements

• 👀 [Dashboard] We added a new "Commits" tab to the workflow page where you can see all commits on that workflow and promote changes.
• 👀 [SDKs] We now support a containerStyle prop for the React Native and Expo SDK's NotificationFeed component.
• 👀 [SDKs] fetchNextPage in the JavaScript SDK FeedClient now supports FetchFeedOptions.
• 🐛 [SDKs] Trigger data filtering now supports boolean values in the JavaScript and React SDK.

Today we're introducing workflow filtering for our commits page. Users can now filter the commits page by workflow to help teams better track and manage changes across their notifications.

Commit log filtering is available for all users on the "Commits" page, within the "Commit log" and "Unpromoted" tabs. Select a workflow from the filter dropdown to see all commits related to that workflow.

Fixes and improvements

• 🐛 [Notification engine] We fixed an issue where MS Teams webhooks would unexpectedly retry a sent notification.
• 👀 [API] We added support for datetime filtering to the user feed endpoint.
• 👀 [API] We added support for listing recipients with their preference sets loaded.
• 👀 [Notification engine] We added support for a new from_markdown Liquid helper to convert Markdown to HTML.

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.