Fabric Activator is the part of Microsoft Fabric that connects real-time insights with automated actions — it’s what makes analytics operational.

At its core, Activator is a no-code service that continuously monitors incoming data from Eventstreams or from KQL queries running on KQL Databases.

It looks for specific conditions that you define — things like a metric crossing a threshold, an anomaly appearing in a time series, or a custom pattern detected across multiple events.

When one of these conditions is met, Activator automatically triggers an action. Those actions might take place inside Fabric — for example, refreshing a dataset, sending a signal to another Fabric component, or marking an event for review. But they can also occur outside Fabric, such as posting a message to a Microsoft Teams channel, sending an email, or starting a Power Automate or Logic Apps workflow.

Activator helps move from passive analytics — where you simply observe dashboards — to active intelligence, where your system responds immediately to what’s happening. It’s designed for situations where time matters — for example, responding to equipment faults, detecting fraud attempts, or managing customer interactions in real time.

Activator is the automation layer of Fabric Real-Time Intelligence. It continuously watches your data for important events and ensures the right actions happen automatically, without manual intervention.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

Just after I was born, my mother and father called me Gregory. Ever since then, everyone has called me Greg. And that included my parents. To the day she died, my mother called me Greg and so did my dad while he was alive (miss you both).

I have friends who tell me that the only time their mothers used their full names was when they were in trouble for some reason.

Official entries

Regardless of what I call myself, and what others call me, every time I need to fill in an official form, I have to write Gregory. I could change that to Greg if I changed my name legally but I’m not going to do that. People who have had previous names will tell you that can add even more complexity.

But I have to say that every time I get an email or letter from a bank, a utility company, etc. or every time I’m addressed by someone in a hospital or government office, they address me as Gregory. Each and every time they do that, at first, I end up momentarily thinking who?.

Then it’s obvious to me that as much as this person is trying to sound friendly, they haven’t managed to do so. It immediately puts a barrier between us. Clearly they don’t actually know me.

Preferred Names

You might think well what can I do about that? or how’s that my problem? or what’s this got to do with SQL?

And I’ll tell you.

Every time you build a computer system or database that has no option for a customer/member/client/patient/etc. to record what they’d like to be called, you add to the problem.

Please consider always having a PreferredName column or something similar in every design you create.

The Digital Twin Builder in Microsoft Fabric Real-Time Intelligence is a design surface for representing real-world systems as manageable, structured entities inside Fabric.

A digital twin is essentially a logical model of something in the real world—such as a device, customer, room, vehicle, or any other object that produces events or has measurable state. The new builder allows you to define these entities directly within the Fabric experience without requiring a separate digital twin service.

The first key idea is that the builder helps you formalize the shape of the entities you’re monitoring. You can create a twin type, define its properties, specify expected data types, and establish relationships between different types. For example, you might define a Vehicle type with properties like speed, fuel level, or location, and relate it to a Driver or Region type. The builder provides templates for common patterns, but these structures can be customised to match the domain the data belongs to.

Another important aspect is the automatic ingestion and updating of twin instances. When events arrive through an eventstream, they can be routed to twin definitions, updating the state of each instance as new data comes in.

This means you don’t have to build your own mapping layer between raw telemetry and a logical model—Fabric keeps the state of each twin current as events flow through the system. This includes support for derived properties, where you can calculate values based on existing attributes, and for stateful logic that tracks changes over time.

The builder also supports rules or actions. Once a twin is defined, you can attach conditions that trigger when certain patterns appear in the data. For instance, you might generate an alert when a sensor reading exceeds a threshold, or when the twin enters a specific state. These rules can integrate with Activator or other Real-Time Intelligence components so the twin becomes an active participant in your overall pipeline.

Integration with the Real-Time Hub is another key capability. Twin definitions, event sources, and actions operate together so that twins act as the conceptual centre point of processing. Instead of working with raw events, you work with named, typed entities that provide structure to real-time analytics and monitoring.

Finally, the visual editor is designed to make the modeling process easier. You don’t need to write code to define the structure, relationships, or actions associated with a twin. The builder supports iterative design: you can adjust definitions, test how data flows into the model, and evolve the structure as your scenario grows.

The Digital Twin Builder gives Real-Time Intelligence a higher-level abstraction for modelling the systems you’re tracking. It reduces the amount of custom code needed to maintain state, offers integration across Fabric’s real-time components, and provides a consistent way to reason about entities as they change over time.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I’ve pointed out in previous blog posts that I’m not a fan of ORMs. What I’m even less of a fan of is code-first design, particularly in combination with an ORM like the Entity Framework.

It might seem cool and shiny and if you are just whipping up a small proof of concept or test app, please feel free to do it, but the minute you think of doing it for enterprise systems, please just don’t. And if you have colleagues wanting to do this, just say no.

For most organizations, the data that they own is one of the most (if not the most) valuable asset the company has. The data will generally outlive generations of applications and just be morphed from shape to shape over time.

The data will often be accessed by many different applications, often created with different technology stacks. You might think you’ll be able to corral all access to the data via your app; and again you’ll be wrong.

So designing the data storage to suit the needs of a single version of a single application at a single point in time, is what we baseball umpires know as a big call.

Umpires know to make calls like this emphatically and confidently.

But this is not a call that you should be making. It’s the quickest way to start building disconnected silos of information that don’t represent the business or how the information in the business is inter-related.

Fabric Maps allow you to visualize spatial data as it changes in real time. When integrated with Real-Time Intelligence, you can stream live data directly from Eventstreams or query current states from KQL databases.

Each map layer can represent different metrics — such as sensor status, delivery vehicle locations, or regional anomalies — updated continuously as new events arrive.

You can also apply time slicers and filters to replay historical activity, helping to analyze event sequences over time.

Maps are especially powerful for IoT, logistics, and operations dashboards, where seeing the live spatial context provides instant insight into what’s happening and where.

This makes them an excellent complement to Power BI visuals and other Fabric real-time dashboards.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I recently received a review copy of Agentic Architectural Patterns for Building Multi-Agent Systems by Dr. Ali Arsanjani and Juan Pablo Bustos from my friends at PackT.

Authors

Dr. Ali Arsanjani is Director of Applied AI Engineering at Google Cloud where he leads a center of excellence bridging research, forward-deployed engineering, and enterprise implementation.

Juan Pablo Bustos is also currently at Google, and serves as a strategic partner to Fortune 50 corporations and global institutions. He specializes in operationalizing AI for the enterprise.

Content

This is a substantial and timely guide for anyone trying to move from generative AI experimentation to production-grade agentic systems. The authors take a deliberately architectural view of the topic, treating agents not as some sort of clever prompt chains, but as distributed systems that need structure, coordination, governance, observability, and fault tolerance.

I like the pattern-first approach that’s presented in the book. Rather than presenting agentic AI as a collection of isolated tools or framework tutorials, they give readers a vocabulary for designing systems: agent routers, supervisor and swarm architectures, blackboard-style knowledge hubs, contract-net marketplaces, consensus mechanisms, human-in-the-loop escalation, agent authentication, real-time compliance monitoring, and more. This makes the book particularly useful for architects and senior developers who need to reason about trade-offs before committing to an implementation.

The early chapters set the enterprise context. They discuss GenAI maturity, agent-ready LLMs, RAG, fine-tuning, model selection, deployment, and AgentOps. This foundation matters because multi-agent systems can easily become expensive, brittle, or opaque if teams jump straight into orchestration without thinking about data, model behavior, context, operational risk, and governance. The authors repeatedly return to the idea that production AI is not just about getting a demo to work; it is about creating systems that remain reliable under real-world pressure.

The middle section chapters on coordination, explainability, compliance, robustness, fault tolerance, and human-agent interaction are particularly useful. They address the issues that many organizations encounter after the initial excitement of agent prototypes: instruction drift, unclear accountability, weak audit trails, fragile tool calls, failures that cascade between agents, and uncertainty about when humans should intervene. The discussion is practical and enterprise-oriented, with examples that help translate abstract patterns into design choices.

The later chapters provide implementation depth through loan-processing examples and comparisons of frameworks such as Google ADK, CrewAI, and LangGraph. I was glad to see they do not pretend that one framework is universally best. Instead, they frame frameworks as implementation vehicles for deeper architectural patterns. That gives the book longer-term value, especially in a fast-changing ecosystem.

If I had to pick a limitation, it would be the breadth, but only if you’re looking for a quick fix. At over 500 pages, the book is comprehensive, but readers looking for a quick, beginner-friendly introduction may find it pretty heavy going. It also assumes you are comfortable with software architecture, Python, APIs, and basic AI concepts. Given the likely audience, I think that’s fair enough.

Solo developers or small teams might need to adapt their guidance to smaller-scale projects, as the primary target is around enterprise applications. But that’s certainly possible.

Summary

This book is a strong reference for practitioners who are serious about building reliable agentic AI. Its greatest strength is that it shifts the conversation from prompts and prototypes to architecture, governance, and production readiness. For technical leaders, AI architects, and senior engineers designing multi-agent systems, I think it will hit the spot.

I liked the book.

8 out of 10

Dashboards are an effective way to visualize data, but not every use case involves a person watching a screen.

In many organizations, the most valuable insights come when real-time intelligence is embedded directly into operational systems.

Microsoft Fabric makes this possible by allowing you to expose query results as APIs — typically REST endpoints built on top of KQL Databases. This means that the same data you’re using in dashboards can also be made available to web or mobile applications, business workflows, or partner integrations.

These APIs can support two main interaction patterns:

Pull model: external applications call the API when they need data — for example, a web app that requests the current sensor status or event count.

Push model: the system sends data or alerts automatically when certain conditions are met — for example, pushing updates to a monitoring dashboard or triggering a webhook when an anomaly is detected.

Both approaches are useful, depending on the type of application. The pull model works well for on-demand queries, while the push model is better suited for continuous updates or alerting.

Exposing real-time data through APIs extends Fabric’s capabilities beyond business intelligence. Instead of limiting insights to dashboards or reports, real-time analytics can directly inform operational decisions, automate responses, or power customer-facing applications.

For example, a logistics platform could use a REST API backed by a KQL Database to surface live delivery data in a mobile app, or a fraud detection system might push alerts into a transaction processing service.

This kind of integration helps ensure that real-time intelligence doesn’t just stay in analytics tools — it becomes part of everyday operations, where it can have an immediate impact.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I recently received a review copy of The New Quantum Era: An Outsider’s Introduction by Sebastian Hassinger from my friends at PackT.

Author

Sebastian Hassinger has held key positions at Apple, IBM, and AWS. He is now an independent consultant and advisor. You can find him on The New Quantum Era podcast.

Content

This is a rare kind of technology book: ambitious, historically grounded, technically serious, and still readable for people who do not have a physics degree. And Sebastian is well placed to write it. He’s had both insider access and outsider sympathy.

This is not a textbook, does not teach quantum programming, and contains virtually no mathematics or code. Instead, the author aims to give readers enough conceptual understanding to interpret scientific claims, marketing claims, and investment hype with more confidence. That’s its first strength. So many quantum books either oversimplify the science into misleading metaphors or bury the reader in formal language. Sebastian takes a third path: he builds context patiently through history, personalities, institutions, business incentives, and the gradual convergence of physics and information theory.

The structure works well. The three broad movements - Theory, Reality, and What We Know and What We Don’t take the reader from Google’s quantum supremacy announcement through the foundations of quantum mechanics and information theory, then into Shor’s algorithm, qubit technologies, hype, fault tolerance, and the uncertain future. The result is less a manual than a guided tour of how a field becomes an industry before it has fully become a technology.

The most valuable sections are the ones that puncture easy narratives. The author is especially good on the disproving the common misconception that quantum computers simply try all possible solutions simultaneously. He explains why that idea is not just imprecise but actively harmful, because it supports inflated claims about quantum computing’s near-term usefulness. His treatment of hype is firm without becoming cynical. He accepts the enormous promise of quantum technologies while repeatedly reminding readers that promise is not the same thing as application.

I’ve been in the industry to have a really strong hype-detector. And this is another area where it’s been going off when reading the marketing.

Sebastian argues that, at the time the book was written, there are no production quantum workloads and no broad economic value from quantum devices, but he also insists that the wave is still building rather than failing. This is a mature position, and it is refreshing in a field often dominated by either breathless optimism or weary dismissal.

If I had to pick a weakness for the book, it’s unfortunately a consequence of its ambition. Some readers may find the historical detours, company names, qubit modalities, and market commentary a bit of a dense read. Those wanting a short what can quantum do for my business? might need patience. By the time he discusses competing qubit approaches and concludes that no single perfect qubit ends the story, the reader understands why the uncertainty itself is the point.

Summary

I’d highly recommended this book for technologists, investors, policymakers, and curious readers who want to understand quantum computing without being seduced by slogans. It is an excellent map of a field still being built.

Well done!

8 out of 10

In the past, if you wanted a real-time Power BI dashboard, you had to use streaming datasets — data pushed directly into Power BI from an external source.

While that approach worked, it came with significant limitations: the data couldn’t easily be joined with historical information, retention was limited, and managing the push model was complex.

That model is now deprecated — streaming datasets shouldn’t be used for new solutions.

The modern approach is to use Fabric Real-Time Intelligence (RTI) with Eventstreams as the ingestion layer. Eventstreams capture and route real-time data, landing it in destinations like a KQL Database, Warehouse, or Lakehouse.

From there, Power BI connects through DirectQuery, enabling near real-time visuals that refresh automatically as new data arrives.

This design offers the best of both worlds — you get low-latency operational visibility, but your dashboards are built on fully queryable, persisted data. That means you can seamlessly combine live telemetry with historical context — for example, comparing this hour’s traffic volume to the same hour last week, or visualizing anomalies against long-term trends.

Updates happen automatically — there’s no need for special streaming visuals or a separate dataset type. Everything is unified under the Fabric platform.

In practice, this shift makes Power BI dashboards more powerful and maintainable. They’re backed by real storage, easily secured and governed, and they scale naturally with the rest of your Fabric environment.

So when you’re building real-time reports today, don’t think of it as streaming into Power BI, but as streaming into Fabric, and then visualizing through Power BI — all within a single, integrated ecosystem.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I work with data. I understand that for most organizations, that the data they own is the most valuable asset the company owns.

One thing I’ve learned from working with data is that unlike application software, data generally outlives generations of applications, is often used by many different applications, and typically just morphs from shape to shape over time. It almost never gets totally refreshed.

This is a good thing.

Immature consultants

I’ve been in the industry long enough to see many types of consultants. One type that I have the least time for, is the type that always wants to tear down or replace whatever is already there at an organization. It’s far easier to just say let’s replace it all than to try to work out what to do.

Many of these consultants don’t really understand what’s already in place, but because it looks different to what they are used to, it must be wrong, and it must be replaced.

Mature consultants

A mature consultant might not like what they see but they take the time to consider what’s already there.

The mature consultant is skilled enough to work out how to take the organization from a place that they don’t want to be, to a place which is better than where they are now.

That’s the real skill.

More SQL love !

Recently at Microsoft Build, Azure HorizonDB was announced. And we’ve just completed our first course using it.

Creating reports, analytics, or applications? And need to get data out of Azure HorizonDB? Learn to write SQL queries like a pro !

We have very popular SQL courses, for T-SQL, PostgreSQL, Snowflake, Oracle, DB2, and MySQL. We’ve just added our new course Writing SQL Queries for Azure HorizonDB and you can enrol in it now. It’s just $95 USD.

Check it out and enrol now here: Writing SQL Queries for Azure HorizonDB

Course Summary

Do you need to learn how to write SQL queries for Azure HorizonDB?

• You know that the information that you need is stored in a Azure HorizonDB database
• You need to find some data to extract it
• You need to create reports with reporting tools
• You are using analytic tools like Power BI, Tableau, QlikView, Excel, or Access and need to get data from Azure HorizonDB
• You want to learn to write queries properly, using commercial coding standards
• You are new to writing queries, or you are self-taught and want to make sure you are doing it correctly

If so, this course is for you! And as well as detailed instruction, the course also offers optional practical exercises and quizzes to reinforce your learning.

We encourage you to complete the practical exercises. We have tried to make this as easy as possible.

Check it out and enrol now here: Writing SQL Queries for Azure HorizonDB

Thresholds are great for simple conditions — but they fall short when what’s normal changes throughout the day, week, or season. That’s where anomaly detection comes in.

Instead of relying on fixed limits, anomaly detection uses statistical and machine learning techniques to model what’s normal for a given signal, then flag data points that deviate from that pattern.

For example, network traffic might be high during business hours but low overnight — a single static threshold would either miss issues or trigger constant false alarms. Anomaly detection adjusts dynamically, recognizing these natural variations in the data.

In Microsoft Fabric, anomaly detection is built right into the KQL query language. You can use functions such as series_decompose_anomalies() to automatically identify outliers in time-series data. These functions can analyze historical trends, detect spikes or drops, and even output an additional column indicating whether each value is normal or anomalous.

Anomaly detection is especially powerful in domains like fraud detection, IoT sensor monitoring, and security log analysis, where patterns are complex and unpredictable.

You can visualize anomalies directly in Fabric Real-Time Dashboards or Power BI, highlighting them with color or markers for quick recognition.

So while thresholds are rule-based, anomaly detection is pattern-based. It helps you monitor systems where normal behavior isn’t static — turning noisy, unpredictable data into clear, actionable insights.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

Memory is a precious resource on most systems today. SQL Server loves memory, so it’s important to avoid wasting it.

One common cause of wasted memory is what we call plan cache pollution. The plan cache is the region where SQL Server stores compiled query plans (and query plan stubs).

There are some nice new DMVs that give you details of what’s in that cache but nothing still compares to one of the older compatibility views sys.syscacheobjects. You can use it to see what’s in your plan cache:

You’ll see the different types of objects that are contained there but the one that’s of interest to us today is the Compiled Plan.

In the image above, I don’t know without looking further if the first three queries shown are actually the same query but they nicely demonstrate one of the issues. Because these plans are looked up via hashes of the queries, it’s really important that every time you call T-SQL code, that you use consistent calling.

Note above that DB_ID() is capitalized in the first row, and not in the next two. Also notice that there is an extra space after db_id() in the third row. All it takes to get different query plans is for anything to be different. Whitespace, capitalization, etc. all matter, even on case-insensitive servers.

What causes the biggest issue with query plans though is how parameters are defined. One big issue with many frameworks is that they don’t define parameters correctly. This was a particular problem with Linq to SQL was that under the covers it called the AddWithValue() method on the SqlCommand.Parameters collection. The problem with that method is it did not define the data type, and Linq to SQL had to derive the data type. What it did was to change the data type based on the length of strings. So “hello” was an nvarchar(5), “freddie” was an nvarchar(7) and so on. And there are still many of these apps in use today.

What this meant is that your SQL Server plan cache could quickly become full of query plans for every combination of every length of parameter that was ever passed to it. In some later variations of this and other frameworks, they just now assign all strings to big buckets like nvarchar(4000) to try to avoid this problem.

It’s one of the reasons that I’m not a fan of ORMs. When you find a problem with something like this, what do you do?

Well what Microsoft did, after they actually caused this problem, was to add an interesting option to SQL Server back in 2008.

EXEC sp_configure 'optimize for adhoc workloads', 1;
GO

RECONFIGURE;
GO

Once this configuration option is enabled, SQL Server doesn’t store a query plan the first time it encounters a particular query. It just stores a small stub so it can remember that it has seen the query before. Then the second time it sees a query, it stores the plan.

I believe this option really should be on for most systems. Yes, it slightly increases the amount of compilation that could occur but it avoids a truly polluted plan cache.

In real-time analytics, thresholds are the simplest way to detect when something goes outside of normal operating conditions.

A threshold is just a fixed value or condition applied to a metric. For example, you might set a rule to flag when CPU usage stays above 90% for more than five minutes, or when transaction latency exceeds two seconds.

In Fabric Real-Time Intelligence, thresholds are typically implemented within KQL queries or dashboard visuals — for instance, using conditional formatting to highlight values above a certain limit, or defining an analytic rule to monitor a KPI in real time.

They’re easy to understand and quick to configure, which is why thresholds are so widely used in operational monitoring.

Thresholds work best when you’re dealing with well-understood metrics — things where you already know what “too high” or “too low” looks like. For example, system performance counters, network latency, or error rates in APIs.

The limitation, of course, is that fixed thresholds don’t adapt — what’s normal at 2 a.m. might not be normal at 2 p.m. That’s why, later in the module, we’ll look at anomalies, which detect unusual behavior dynamically rather than relying on fixed cutoffs.

And when we discuss Activator in future posts, you’ll see how these thresholds can feed directly into triggers and workflows — turning simple conditions into automated actions.

Think of thresholds as the starting point for real-time alerting: simple, transparent, and effective for quick wins.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I spend most of my life in a variety of customer sites. Most of these nowadays tend to be large financial organizations. When I talk to developers in those organizations, and ask them about how they interact with their DBAs, I can’t tell you how often I hear that they try to avoid ever making schema changes, etc. as it takes too long and the process is painful.

When I talk to the DBAs at the same organizations, and I ask them why they resist making schema changes, I hear this:

If they change the database, they believe someone will scream at them, but they don’t know who because:

• They have no visibility on the code that touches the database so
• They do not know what they are about to break.

So where is this code that the DBAs can’t see or test?

• Embedded in applications (or generated within the application dynamically) – often in widely-differing technology stacks (.NET, Java, etc.)
• Embedded in Excel spreadsheets
• Embedded in Reporting Services Reports
• Embedded in Power BI Dashboards
• Embedded in Analysis Services data sources
• Embedded in SSIS Packages or ADF or Fabric pipelines
• Embedded in Access databases
• And so on and so on.

What this means is that if the DBAs want to change the database, they have absolutely no way of knowing, at all, what they are about to break, unless they have tested every spreadsheet, have run every option in every report, have run every combination of SSIS packages, have reprocessed every analytic data model, have used every feature in every application, etc, etc.

That’s never going to happen, so what do they do? They push back on any changes.

If I talk to the developers, and ask them why they built this pile of cards, I’m invariably told that they had to be agile. Yet what they don’t understand is that what they have built is the complete opposite of agile. They have actually built a house of cards where no-one is game to touch anything. And we know where that all ends.

This is why I’m so much of a fan of having at least one layer of abstraction (yes that’s procs and views) within the database. Then at least, the DBAs have visibility in the code touching the database.

In a slightly better world, the data people would also have unit tests wrapped around those procs and views. Then, when they need to make a change, they could just re-run the tests, and at least know that they haven’t broken every report, spreadsheet, etc. in the organization.

I know that many might disagree, but I believe that if you are putting anything that looks like T-SQL logic directly into an application, into a spreadsheet, Reporting Services report, Analysis Services data source, Access database, etc., you’re building a problem faster than you’re building your applications.