Log icon
If icon
TeamsIncomingWebhook icon
RealtimeTrigger icon
SlackIncomingWebhook icon

SQL Server CDC to Microsoft Teams via Debezium

Orchestrate SQL Server change data capture with Kestra and Debezium. Trigger one execution per row change and alert Microsoft Teams, without deploying Kafka Connect.

Categories
Data

Turn SQL Server's built-in change data capture into a real-time event stream without deploying and operating Kafka Connect. This blueprint uses Kestra's Debezium SQL Server connector to create one execution per row change on a CDC-enabled table, logs every change for audit, and posts a Microsoft Teams alert only when a changed order crosses a value threshold, so the operations channel is not flooded with routine updates.

How it works

  1. capture_order_changes (io.kestra.plugin.debezium.sqlserver.RealtimeTrigger) connects to the SQL Server instance and streams row-level changes from the sales.orders table in real time. snapshotMode: INITIAL takes a full snapshot on first start, then switches to streaming; format: INLINE exposes the row's columns directly under trigger.data, and trigger.stream carries the source table name.
  2. log_change (io.kestra.plugin.core.log.Log) records every captured change for a complete audit trail, independent of whether it triggers a downstream alert.
  3. high_value_change (io.kestra.plugin.core.flow.If) evaluates trigger.data.total > 5000. When true, notify_teams (io.kestra.plugin.microsoft365.teams.TeamsIncomingWebhook) posts an Adaptive Card style alert to the operations Teams channel with the changed row's stream and data.
  4. The errors block posts a separate Slack alert if processing a captured change fails, so a broken downstream step never fails silently.

What you get

  • Real-time SQL Server CDC without Kafka, Kafka Connect, or a separate Debezium server to operate.
  • One Kestra execution per row change, each with full input, output, and log capture for replay.
  • Selective Teams alerting on high-value changes only, keeping routine updates out of the channel.
  • A separate Slack failure channel so CDC processing issues surface immediately.

Who it's for

  • Data engineers who need SQL Server CDC without standing up a Kafka Connect cluster.
  • Platform teams replacing custom Debezium server deployments with a managed trigger.
  • Operations teams who want selective alerting on business-critical row changes, not every row.

Why orchestrate this with Kestra

Debezium's typical deployment model runs as a Kafka Connect connector, which means operating Kafka, Kafka Connect, and topic management just to react to a SQL Server row change. SQL Server Agent has no visibility into CDC events at all; it only runs scheduled jobs. Kestra's io.kestra.plugin.debezium.sqlserver.RealtimeTrigger embeds the Debezium engine directly, so a captured change starts a Kestra execution with no external streaming platform. From there, the full plugin catalog (branching, notifications, downstream writes) is available with retries, execution history, and replay.

Prerequisites

  • A SQL Server instance with CDC enabled on the source database and the sales.orders table (EXEC sys.sp_cdc_enable_db; then EXEC sys.sp_cdc_enable_table for the target table).
  • Network access from the Kestra worker to the SQL Server instance on port 1433.
  • A Microsoft Teams incoming webhook and a Slack incoming webhook.

Secrets

  • SQLSERVER_HOSTNAME: hostname of the SQL Server instance.
  • SQLSERVER_USERNAME / SQLSERVER_PASSWORD: SQL Server credentials with CDC read access.
  • TEAMS_WEBHOOK_URL: Microsoft Teams incoming webhook URL for high-value alerts.
  • SLACK_WEBHOOK_URL: Slack incoming webhook URL for failure alerts.

Quick start

  1. Enable CDC on the source database and the target table in SQL Server.
  2. Add the secrets above to your Kestra namespace.
  3. Set database and includedTables to match your CDC-enabled database and table.
  4. Deploy the flow and update a row in the source table to watch an execution fire.

How to extend

  • Adjust the high_value_change threshold or add more branches for other business rules.
  • Replace log_change with a write into a downstream cache, search index, or reporting table.
  • Swap RealtimeTrigger for io.kestra.plugin.debezium.sqlserver.Trigger to batch changes on a polling interval instead of one execution per row.
  • Chain a Kafka producer task after log_change if downstream systems still expect a topic.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.