Changelog

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.

Override the recipient of an email

Today we're adding support for overriding the recipient of an email generated in Knock. Previously, emails were always sent to the email address associated with the recipient.

With the new to email override, you can now specify either a static or dynamic value via liquid for the recipient of an email. For example, you might be sending a change email confirmation to the user, but be sending it to the new email address they entered and stored on the recipient profile as recipient.new_email.

You can read more about the feature in our email overrides documentation.

Immediately flush the first item in a batch

Today we're excited to extend our batch step with support for immediately flushing the first item in the batch. Previously, our batch step would collect all triggers across the batch window, and flush those as a single batch once the window closed.

With immediate flushing, your batch will always flush the first item before accumulating subsequent triggers across the batch window. If you're a developer, you might be familiar with this concept as a "leading debounce". This can be useful when you want to immediately notify your users about some action occurring, while still batching any additional information across a window of time to reduce the number of notifications your users receive.

You'll find the option to immediately flush the first item in the batch under the advanced options in the batch step settings. You can read more about the feature in our batch step documentation.

Fixes and improvements

• 👀 We added support for sending multiple tags to Mailgun via overrides.
• 🐛 We moved our OneSignal integration to use the v11.6 API.
• 🐛 We added a role="none" attribute to any open tracking pixels included in emails.
• 🐛 We fixed an issue where identify events sent to Segment would override properties set on the user being identified.

Bot framework support for Microsoft Teams

Today we're excited to announce that we've added support to our Microsoft Teams integration for sending notifications via bots through the Microsoft Bot Framework. While we've previously had support for Microsoft Teams as a provider in Knock, our integration only supported sending via webhooks, which was most suitable for internal or one-off use cases.

Using the Bot Framework, we can now support multi-tenant integrations that can send messages to channels and directly to users, making it possible to build richer notification experiences on top of Microsoft Teams and powered directly through Knock.

You can read more in our refreshed Microsoft Teams documentation on how to get started.

Fixes and improvements

• 👀 We've added inline step editing to the workflow builder for the step name, description, and reference fields.
• 👀 We added support for navigating the workflow builder using the keyboard. You can now use the arrow keys to easily select different steps and navigate your workflows.
• 🐛 We fixed a bug where long workflow keys would wrap in the workflow list.
• 🐛 We fixed an issue where email template setting overrides were not being saved because of invalid override JSON being provided.

Introducing in-app message types

Today we're excited to announce the beta release of in-app message types. Building on our in-app messaging components release, with today's release you can now power any UI element in your product—a banner, a carousel, a tag, anything—using Knock's workflow engine and real-time messaging infrastructure. Here's how it works.

In-app message types enable you to map UI elements and components from your application to a message type in Knock. Once you've created a message type, you can use it to target and send native messages to that component in your own product, powered by Knock's real-time messaging infrastructure.

In-app message types are a powerful way for your engineering team to own the structure and implementation of in-app messages displayed to your users, while giving product managers and marketers the flexibility to create and manage the in-app messages sent to your users through Knock's powerful visual workflow builder.

Each in-app message type has a schema that determines the fields available to your content editors when building a new in-app message. Schemas are versioned and can be updated over time to create strong guarantees between the structure expected in your components and the messages exposed over the API.

To render components for a given message type, you use our React SDK and hooks to fetch any messages of that type for the current user. Knock owns the data layer, while your team owns the component, making it possible to create native in-app messaging that leverages your existing design system and component library. This also means that native in-app messaging powered with Knock is just as performant as the rest of your app, and won't be blocked by ad blockers. You can read more and see examples in the documentation.

In-app message types are currently in beta. If you're interested in trying them out, please contact our team.