When every row matters in real time

Operational systems run on databases. Inspections on the factory floor, patient admissions in the hospital, orders in the retail backend. Most meaningful business events start as rows written to a table. They land in the database, get replicated to a warehouse, and surface in a dashboard the next morning. By then the bad batch is shipped, the high-value customer has churned, the patient is already in the wrong ward.

Microsoft Fabric closes that gap with three building blocks that compose naturally. This is the row-to-action pattern. Every meaningful operational change becomes available for streaming analytics, and automated response, without standing up a bespoke CDC pipeline.

• Mirroring continuously replicates your operational database (Azure SQL, PostgreSQL, Cosmos DB, Snowflake, Oracle, or an Open Mirroring partner) into OneLake as Delta tables.
• Mirrored Database Extended Capabilities turn on Delta Change Data Feed (CDF) on the mirrored database, so Fabric captures every row-level insert, update, and delete as it happens, ready for incremental consumption.
• Eventstream Connector for Mirrored Database Change Feeds (Preview) streams those CDF changes directly into Fabric Eventstreams, a real-time stream processing pipeline where you can filter, aggregate, route, and act on them in flight.

For the rest of this post, we'll use a manufacturing scenario as our running example — a discrete-manufacturing line whose Manufacturing Execution System (MES) records every inspection result.

The inspections themselves come from automated optical-inspection (AOI) stations, inline sensors, and end-of-line test equipment that score parts in milliseconds and write a row per part — station_id, part_number, result (PASS/FAIL), defect_code, timestamp — to an operational database behind the MES.

The same pattern applies wherever real-time response on operational data matters. Today, that line's MES writes to a database, analysts query yesterday's data, and dashboards refresh on a schedule. By the time a defect cluster shows up in a chart, the bad batch is already packed; what's been missing is a path from "row changed" to "operator notified" that doesn't require Spark expertise or custom plumbing.

What Eventstream brings to the change feed

Eventstream is the part of Fabric that ingests, processes, and routes real-time events. The Mirrored Database Change Feed connector is one of many source connectors that bring events into an Eventstream — and once they're flowing, Eventstream gives you three things at once:

• A set of connectors & streaming pipeline that carries change events from the source into Fabric with low latency and at scale.
• A Fabric portal page (and corresponding REST APIs & AI skills) you can use to filter, shape, and aggregate the stream using built-in SQL operators or no code operators.
• A set of output adapters that fans the processed stream out to multiple destinations in parallel: Eventhouse for live KQL analytics, Activator for automated triggers, Lakehouse for historical analytics & data science workflows, or to external systems via custom endpoints.

The next three sections walk through how each of those roles shows up in a production-line quality flow.

Figure: From MIrrored Operational Database to Operator Action using Eventstream, real-time alerts and dashboards.

Shape change feed events with Eventstream SQL operators

The first thing most teams want to do is narrow the firehose to the events that matter. For a quality-intelligence flow, that means keeping only the failed inspections, projecting the columns the rest of the pipeline needs, and emitting them on a named stream:

SELECT
    station_id,
    part_number,
    defect_code,
    EventEnqueuedUtcTime AS ts
INTO [FailedInspections]
FROM [MESCdfStream-stream]
WHERE DeltaTable = 'Inspections'
  AND result = 'FAIL'
  AND _change_type IN ('insert', 'update_postimage');

In plain English: from the Inspections change feed, keep only the failed inspections that came from new rows or updates (skipping pre-image rows and deletes), forward just the columns the rest of the flow needs, and emit them on a named output stream that the downstream operators subscribe to.

To learn more, refer to Eventstream SQL operator reference for the full Filter, ManageFields, and GroupBy surface.

Detect defect clusters with windowed aggregations

Single failed inspections happen all the time — what operations cares about is clusters. A short GroupBy over the [FailedInspections] stream, keyed on station_id and bucketed into a 1-minute tumbling window, surfaces them as they form:

The same Eventstream SQL operator can be used to express this against the [FailedInspections] stream emitted by the previous query:

SELECT
    station_id,
    System.Timestamp() AS window_end,
    COUNT(*) AS fail_count
INTO [StationFailureClusters]
FROM [FailedInspections]
GROUP BY station_id, TumblingWindow(minute, 1);

Every minute, the query counts the failed inspections per station and emits one row per station per window on the StationFailureClusters output. That's the stream Activator subscribes to in the next step. Tune the window size to your line rate; refer to the Eventstream SQL windowing reference for the full set of window types and options.

Trigger floor action with Activator

Eventstream detects and routes the signal. Activator turns that signal into an operational action. Point an Activator item object at the aggregated stream, define a condition ("failure count per station ≥ 5 in any 1-minute window"), and attach an action. Post to a Teams channel, send an email to the line supervisor, or trigger a Power Automate flow that opens a maintenance ticket or invokes a webhook into your downstream systems.

Because Activator subscribes directly to the Eventstream output, the same change event that landed in OneLake seconds ago can result in a paged maintenance technician at the close of the very next aggregation window. No polling, no scheduled job, no custom listener service.

Power live KQL dashboards with Eventhouse

For yield and trend analytics, Eventhouse — a database optimized for high-volume, high-velocity, time-series queries — works best when it receives the raw inspection stream, not just the failure-only branch. Routing the raw stream (pre-filter) to Eventhouse keeps both passes and fails in the table, so yield math works correctly. Once it's there, a real-time KQL dashboard gives quality engineers and line managers a single live view — defects per station, rolling yield, top defect codes — that updates within seconds of each change:

Inspections
| where ts > ago(15m)
| where _change_type in ("insert", "update_postimage")
| summarize fails = countif(result == "FAIL"), total = count() by station_id
| extend yield_pct = round(100.0 * (total - fails) / total, 1)

The query keeps only the change rows that represent a new or updated inspection over the last 15 minutes, counts failures and totals per station, and computes yield percentage. Pin it to a KQL dashboard and you have a live quality wall display that stays current without manual refresh.

End-to-end: From inspection write to paged technician in roughly 90 seconds

From the moment an inline AOI station scores a part as FAIL and the MES writes the row, the change lands in OneLake, flows through the Eventstream, trips the Activator condition at the close of the next 1-minute window, and pages the technician. In a low-volume test scenario the whole loop completed in roughly 90 seconds, split across:

1. Mirroring + Delta CDF availability: Source DB write volume and mirroring lag (usually seconds to minutes)
2. Eventstream ingestion + transformation: Capacity load and backpressure (sub-second to seconds)
3. Tumbling window close: Up to the window size you choose (here, 60 s)
4. Activator evaluation + action dispatch: Teams / Power Automate latency (usually seconds)

In production, tune the window size and threshold to your line rate, and add alert suppression or escalation rules so repeated windows don't page the same team unnecessarily.

Beyond the production line

The same pattern applies to any domain where operational change needs to drive an immediate response:

• Retail: Mirror the inventory database, filter the change feed to rows where on-hand quantity drops below the reorder threshold, aggregate by store, and let Activator notify store managers and trigger replenishment workflows within a minute of the stock-out signal.
• Healthcare: Mirror the bed-management database, watch for rooms transitioning from "occupied" to "cleaning," and let Activator notify housekeeping so turnaround times drop and incoming admissions land in clean rooms faster.
• Logistics: Mirror the shipment-exception database, group exceptions by origin facility in 10-minute windows, and surface clusters on a live map so the operations team can dispatch recovery before customer complaints start rolling in.
• Financial services: Mirror the transaction database, filter for high-value transactions outside a customer's usual pattern, and let Activator escalate to the fraud team while a live Eventhouse dashboard tracks the day's anomaly rate.

In each case, the building blocks are the same — only the table and the threshold change.

Get started today

To build your own real-time intelligence flow on Mirrored Database Change Feeds:

1. Mirror the source — Set up a Mirrored Database for the operational system that holds your quality or operations data.
2. Enable Delta CDF — Turn on Extended Capabilities on the mirrored database from its configuration dashboard or via the API.
3. Wire up the Eventstream — In the Real-Time Hub, create an Eventstream and add the Mirrored Database Change Feed connector as the source.
4. Shape, aggregate, and act — Add Filter, ManageFields, and GroupBy operators in the canvas, then route the output to Eventhouse for dashboards and to Activator for triggers.

Explore the following resources:

• Microsoft Fabric Eventstreams overview
• Mirrored Database (Change Feed) source for Eventstream (Preview)
• Extended Capabilities in Fabric Mirroring
• What is Fabric Activator?
• Eventhouse overview and KQL database documentation

We'd love your feedback!

If you find this blog helpful, please give it a thumbs-up! Have ideas for what you'd like to see next? Drop us a comment or reach out to [email protected] — we'd love to hear what real-time scenarios you're building and what topics you'd like us to cover in future posts.

Have new feature ideas? Submit them at Fabric Ideas - Microsoft Fabric Community.