Real-Time Intelligence in plain words: the path of one event

What is Real-Time Intelligence in Microsoft Fabric

Real-Time Intelligence is the Microsoft Fabric workload for data in motion. It takes events in and keeps them in a database built for time. It shows them on live dashboards and acts on them with rules. Microsoft Learn says it reacts to events as they happen, instead of running on a schedule. For a beginner, it is five parts with one job each.

Dr. Kot taught it this way at a community session in Doha, described in Part 1, the overview. This part follows one event through all five parts, from a booth to an email.

The story: an oud fragrance house retests formula OB-106, Oud Daylight, with 40 testers at a launch evening. Each tester smells two paper strips, called blotters. One carries the new formula, the test. The other carries the current formula, the reference. The tester reaches for one first. In the earlier study ST-15, OB-106 reached 53 percent first choice. The business calls a formula a winner above 60 percent.

What an event is, and why you design it first

An event is one small fact that just happened, with a time stamp. In the demo, one event means one tester finished one paired blotter test. The booth sends one line of JSON with ten fields. Forty testers send forty events. Every later part reads these ten fields, so their shape decides how simple the rest of the build stays.

Here is tester 1, with the example time from the session design:

{
  "event_time": "2026-10-14T18:45:12+03:00",
  "study_id": "ST-16", "trial_id": "TR-2008", "formula_id": "OB-106",
  "tester_id": "T-001", "booth_id": "BOOTH-1", "panel_site": "Panel C",
  "first_choice": "reference",
  "dwell_test_s": 63.0, "dwell_reference_s": 101.8
}

Read as a sentence: at 6:45 PM, tester T-001 at booth 1 reached for the reference blotter first. The tester held the test blotter for 63.0 seconds and the reference for 101.8. It is one vote for the current formula.

Dr. Kot's position: design the event before any Fabric item exists. Three choices keep every later step short. The event is flat, so it maps to one table row without parsing. The choice is a two-value text, so the share is one count divided by another. Every event carries the trial ID, so the rule can follow each trial on its own.

The design to avoid is a device that sends a total instead of the fact. A booth that sends “share so far: 58 percent” hides the votes. One lost or repeated message then breaks the total, and the Eventhouse cannot recompute it. Send the raw fact. Compute the number in one place.

Eventstream: the pipe, with a custom endpoint

An Eventstream is the Fabric item that carries events in. It receives events from sources and routes them to destinations without code. The demo stream, es_blotter, had one source, a custom endpoint called booths, and one destination, the table blotter_events. Learn notes that an Eventstream does not store data permanently. It passes events on.

A custom endpoint is the source for your own application. Learn says it gives you a connection string in Event Hubs format, with AMQP and Kafka as other options. The demo script used the Event Hubs format and one Python package, azure-eventhub.

Treat that connection string as a password, because it carries a shared access key. Keep it in an environment variable, never on a slide or in a repository.

Eventhouse and KQL database: where the number comes from

An Eventhouse is a database built for events. Learn says it organizes data by the time it arrived, so questions about recent data stay fast. One Eventhouse holds one or more KQL databases, and each database holds tables. The demo had one Eventhouse, eh_oud, with one table, blotter_events. Two saved functions turn its rows into the number the business cares about.

The first function, running_share(), is for the dashboard. It sorts events by time, then by tester ID. For each tester it counts testers so far and test votes so far. It divides one by the other and rounds to one decimal. After a full run it returns 40 rows, and the last one shows 65.0.

The second function, activator_state(), is for the rule. It reads running_share() and keeps only the latest row for each trial. It drops that row while fewer than 20 testers are counted. It returns at most one row per trial. Here it is, only to show where the number comes from:

running_share()
| summarize arg_max(n_testers, *) by trial_id
| where n_testers >= 20
| project trial_id, formula_id, n_testers, first_choice_pct

The summarize line keeps the latest row. The where line is the minimum-count guard. The guard lives in the query, not in the rule.

The rule cannot read running_share() directly. Learn explains that Activator runs a KQL query on a schedule and turns every returned row into an event. It stamps each event with the time of the run, not a time from the data. So the query must return the current state. The full running share would hand the rule 40 events on every run.

Real-Time Dashboard: built by Copilot from one sentence

A Real-Time Dashboard is a page of tiles. Each tile runs a KQL query on an Eventhouse and refreshes as new data arrives. In the session design, Copilot builds the dashboard from one sentence typed on the Eventhouse page. The sentence names the function, the measure, and the line at 60. Copilot writes the queries and picks the visuals.

“Show the running first choice share per trial over time from the running_share view, with a line at 60.”

Name the function in the prompt. From the raw table, Copilot may chart a count of events instead of a share.

Copilot generation status: TBC. The Learn release status page lists Generate a real-time dashboard as GA. The how-to page carries no label. In a recorded FabCon recap demo, the Copilot pane showed a Preview label. The Copilot for Real-Time Intelligence post shows that demo and tracks the status.

The requirements on Learn are firm. Copilot needs a paid F2 or P1 capacity or larger, never a trial, and the Copilot tenant setting. Outside the US and EU, Copilot is off until an admin allows processing outside the capacity's region. In Qatar, plan that conversation before the project starts.

The kit also carried a fallback dashboard, built through the API before the session. It had three tiles: the running share with a line at 60, the share now, and the testers so far. It refreshed every 30 seconds. On stage, Copilot built the dashboard live, so the fallback was not needed. Learn now describes Live refresh, on by default for new dashboards, which updates a tile when new data lands.

A dashboard needs a person who looks at it. Nobody at a launch evening watches a chart for 16 minutes.

Activator: the rule is the product

Activator is the Fabric item that watches data and acts when a condition is met. According to Learn, it can send an email or a Teams message. It can also start a Power Automate flow or a Fabric item. The demo rule in plain words: when first choice goes above 60 with at least 20 testers, send a message. It sends one email per trial.

Dr. Kot's position: the dashboard serves people who want to see the trend. The rule is the product, because it turns the trend into an action at the right moment, with nobody watching.

Here is the rule as built, read from its exported definition. The source is the function activator_state() in eh_oud, run every 60 seconds. The object is Trial, keyed by trial_id, with two attributes, first_choice_pct and n_testers. The condition is “becomes greater than 60.” The action is an email with the subject “Winner: a formula passed 60 percent first choice.”

The condition type decides whether the rule fires once or every minute. Learn describes two ways to alert on a KQL query. The “on each event” method alerts for every returned row on every run. A Numeric change condition, such as increases above 60, works differently. It fires only when the value moves from not meeting the condition to meeting it. The demo used the second kind.

With “on each event” and a 60-second check, the rule would email once a minute. It would go on from the crossing until someone cleared the table. That is an estimate, not a measurement. Learn caps email at 30 messages per rule, per recipient, per hour.

Learn allows email only to internal addresses in the creator's tenant. A workshop alert must go to an account in that tenant. Put the numbers in the message, too. The design asked for trial_id, n_testers, and first_choice_pct in the message context, but the exported definition lists no context fields. An email that says only “a formula passed 60” sends people back to the dashboard.

Why the rule waits for 20 testers

A share computed on a few testers moves in large steps. At tester 5, one tester is 20 percent of the count. At tester 31, one tester is about 3 percent. A rule that fires on the first value above 60 fires on noise. The demo rule ignores testers 1 to 19. It fires only when the share passes 60 after that. Both figures are simple arithmetic.

The share starts at 0, because tester 1 chose the reference. It touches exactly 60.0 at tester 5, with three test votes in five. From tester 6 to tester 29 it stays between 44.4 and 58.6. It reaches 60.0 again at tester 30. It passes 60 at tester 31, with 19 test votes in 31, which is 61.3 percent. It ends at 26 of 40, 65.0 percent.

This sequence never puts the guard to a hard test. The early peak touches 60 but does not pass it. Suppose tester 6 had chosen the test blotter instead. The share would have been 4 of 6, or 66.7 percent. A rule without the guard would have fired at tester 6. That counterfactual is the case the guard exists for.

A guard limits noise. It does not remove it. At 20 testers, one tester is still 5 percent of the count. Treat 20 as a business choice, like 60, and write both numbers into the rule. Dr. Kot's rule of thumb: never put a threshold on a share without a count next to it.

What “real time” means in this demo

In this demo, real time means within about one minute. The booths send one event every 24 seconds. Tester 31 arrives 12 minutes after the start. Activator runs its query every 60 seconds, so the alert follows within one check after the share passes 60. Every delay in the chain is a setting, and none of them is zero.

On stage, the alert arrived after tester 31, as the session plan expected. The delay from the booth to the alert was not measured. Learn sets the default query frequency for a KQL source at 5 minutes. With the default, the alert could arrive up to 5 minutes after tester 31.

A shorter check costs capacity. Learn says that querying more often activates rules sooner and uses more capacity. Another Learn page adds that a query every 1 or 5 minutes keeps the Eventhouse always on. An idle Eventhouse costs less.

Activator can also read an Eventstream directly, with subsecond latency for stateless rules, according to Learn. That path sees one tester at a time. The rule needs a share over all testers so far, and that share lives in the Eventhouse.

Real time also depends on capacity. Under overload, Learn says Activator first slows or blocks its interface and keeps evaluating rules. After 24 hours of overload, rule evaluation pauses. Close other workloads on the capacity before a live demo.

The path of one event, from booth to alert

Follow tester 31, who pushes the share past 60, through all five parts. Steps E1 to E5 follow the session architecture.

Step E5 is where the same 60 returns, in a second place. In Activator, 60 is a threshold that sends an email. In the ontology Preview, 60 is a written definition of the word winner that agents read. Learn says an ontology rule is a natural-language definition, and the ontology does not run it against data. The new ontology experience has no Activator integration today. So the rule lives in two places, and you keep both in step by hand. Part 3 explains what an ontology is, and why a data agent needs the same rule.

Reset between runs

Every rehearsal fills the table. Before the next run, clear it with one management command:

.clear table blotter_events data

Learn says the command clears the data of an existing table, including streaming ingestion data. It needs Table Admin permission or higher. The table, both functions, the stream, and the rule stay in place.

Then check three things. The dashboard shows an empty chart. The rule is still on. Nobody starts the script before the first demo beat. After the session, pause the capacity or delete the workspace. A rule that queries every 60 seconds keeps the Eventhouse awake.

What the demo does not show

The demo shows the mechanics on 40 events. Four gaps matter most before a production build.

• Scale. Forty events in about 16 minutes, on an F32 capacity in a dedicated workshop tenant. Throughput, ingestion delay, and cost were not measured.
• Late events. running_share() recomputes the whole history on every run. A late event takes its place by event_time, and earlier points of the line change.
• Duplicate events. The function counts every row, so a tester sent twice counts twice. The tester_id field makes a duplicate check possible. The demo has none.
• More than one trial. The tester count runs across the whole table. A second trial needs a count that restarts for each trial.

Part 5 lists the gaps between this demo and production.

The session kit, with the trial event simulator, is public on GitHub. The handout was shared through the Fabric Falcons community. For the wider build order, see the Microsoft Fabric implementation guide. To review an event design or an alert rule with Dr. Kot, book a slot.

Key facts at a glance

Product facts from Microsoft Learn, checked on November 3, 2026. Demo facts from the session kit.

Frequently asked questions

What is Real-Time Intelligence in Microsoft Fabric?

Real-Time Intelligence is the Microsoft Fabric workload for data in motion. An Eventstream carries events in, and an Eventhouse stores and queries them. A Real-Time Dashboard shows them, and Activator acts on them with rules. Each part has one job.

What is the difference between an Eventstream and an Eventhouse?

An Eventstream carries events and routes them to destinations. Microsoft Learn says it does not store data permanently. An Eventhouse is the database where events stay, organized by arrival time and queried with KQL.

Can Copilot build a Real-Time Dashboard in Fabric?

Yes. On the Eventhouse page, select Generate with Copilot under New Real-Time Dashboard and describe the dashboard you want. It needs a paid F2 or P1 capacity, not a trial, and the Copilot tenant setting. Outside the US and EU, Copilot stays off until an admin allows processing outside the capacity's region.

How often does Activator check a KQL query?

Every 5 minutes by default, according to Microsoft Learn. You change it under Run query every on the query source. A shorter interval activates rules sooner and uses more capacity. The demo in this post used 60 seconds.

Why does my Activator alert fire on every run instead of once?

This happens when the rule alerts on each event. With a KQL source, Activator turns every returned row into an event on every run. To alert once, assign the rows to an object, such as a trial. Then use a Numeric change condition, such as increases above 60. It fires only on the transition.

Does Real-Time Intelligence work on the Fabric free trial?

Yes, for the core parts. Microsoft Learn says the 60-day trial capacity supports all Fabric workloads. Copilot is not supported on trial capacities, so a dashboard generated by Copilot needs a paid F2 or P1 capacity.

Sources

Microsoft Learn, checked on November 3, 2026.

• What is Real-Time Intelligence?
• Get data into Microsoft Fabric
• Add a custom endpoint or custom app source to an eventstream
• Eventhouse overview
• Generate Real-Time dashboards with Copilot
• Release status of AI and Copilot experiences in Fabric
• Live refresh in Real-Time Dashboard
• What is Fabric Activator?
• Ingestion from KQL Querysets
• Query frequency for query data sources
• Create Activator alerts from a KQL Queryset
• Activator limitations
• How Fabric capacity throttling affects Activator
• .clear table data command
• Try Microsoft Fabric for free
• Create and manage business rules in ontology (preview)