Data Activator turns your Fabric environment into an active, event-driven platform — not just a reporting system. Learn how to define objects, properties, and trigger conditions against Power BI reports and Eventstreams, then wire up automated responses including Teams notifications and live pipeline runs.
Picture this: your company's e-commerce platform is running a flash sale. Your real-time sales pipeline is ingesting order data every few seconds, and you've built a beautiful Power BI dashboard showing revenue, inventory levels, and conversion rates. But you and your team are in meetings, not watching dashboards. At 2:47 PM, inventory for your top-selling SKU drops to zero — and nobody knows for 40 minutes. By then, customers have bounced, carts have been abandoned, and the moment has passed.
This is exactly the problem Data Activator was built to solve. Rather than expecting humans to watch dashboards or write custom polling logic, Data Activator lets you define conditions directly against your data and fire automated responses when those conditions are met — whether that's sending a Teams message, triggering an email, or kicking off an entire data pipeline. It turns your Fabric environment from a passive reporting system into an active, event-driven platform that takes action on your behalf.
By the end of this lesson, you'll be able to configure Data Activator from both Power BI reports and real-time Eventstreams, write meaningful trigger conditions, and wire up automated responses including pipeline runs. You'll understand the data flow model that makes it all work, and you'll have built a working end-to-end alerting scenario you can adapt for production use.
What you'll learn:
You should be comfortable with the basics of Microsoft Fabric before diving in. Specifically, you'll benefit from:
Before you touch the UI, it's worth spending a moment on the mental model, because Data Activator introduces a few concepts that don't map directly to anything else in the Fabric ecosystem.
Data Activator is built around a Reflex item. Think of a Reflex as the container for all your alerting logic for a given subject area — your sales monitoring, your pipeline health checks, or your IoT sensor rules. Inside a Reflex, you work with three layers of abstraction:
Objects are the things you're monitoring. In an e-commerce context, an object might be a Product SKU, a Store, or an Order. Objects have identity — you can track multiple instances of the same object type, so your rules run independently per SKU rather than across all SKUs combined.
Properties are the measurements or attributes you're tracking on each object. For a Product SKU object, you might have properties like CurrentInventory, HourlySalesVelocity, and RevenueToDate. Properties pull their values from your connected data source — either a Power BI visual or an Eventstream.
Triggers are the conditions you define on properties. A trigger watches a property and fires an action when a condition is satisfied — for example, when CurrentInventory drops below 50 units for any given SKU.
This object-property-trigger model is important because it means Data Activator is stateful. It knows the last value it saw for each object instance, and it can detect state transitions — not just "is this value low right now" but "did this value just cross a threshold." That's what distinguishes it from a simple threshold alert.
Key insight
Data Activator evaluates conditions at the object instance level, not at the aggregate level. If you have 200 SKUs streaming through an Eventstream, each SKU gets its own property state tracked independently. A trigger for "inventory below 50" will fire separately for SKU-1042 and SKU-7891 — not once because some global average crossed a line.
The easiest entry point to Data Activator is through a published Power BI report. This approach works well for business metrics that are refreshed regularly but don't need true real-time evaluation — think daily sales dashboards, pipeline SLA monitoring, or financial KPI tracking.
Navigate to your published Power BI report in the Fabric portal. Find a visual showing the metric you want to monitor — for this example, let's say you have a table visual showing StoreID, StoreName, and DailySalesTotal for all your retail locations.
To create a Data Activator trigger, hover over the visual and look for the ellipsis menu (the three dots in the upper right of the visual). Select Set alert. This will open a side panel that walks you through the initial configuration.
In this panel, you'll see:
DailySalesTotal)For simple email or Teams notifications, the side panel is sufficient. But if you want to trigger pipeline runs, implement complex conditions, or manage multiple triggers for the same data, click Open in Data Activator. This creates a new Reflex item in your workspace and opens the full Data Activator designer.
Tip
Data Activator can only see measures and fields that are visible in the visual you right-click. If you need to monitor a value that isn't currently shown in a report visual, you'll need to either add it to an existing visual or build a dedicated monitoring visual. A card visual showing a single KPI is a perfectly valid approach for this.
When you connect a Power BI visual to Data Activator, Fabric doesn't create a live streaming connection. Instead, it evaluates the visual's data on the same schedule as your semantic model refresh. If your model refreshes every 30 minutes, Data Activator sees new data every 30 minutes.
This means the latency of your alerts is bounded by your refresh cadence. For many business scenarios — catching a store that's underperforming by mid-morning, flagging a KPI that's gone red — 30-minute latency is completely acceptable. For inventory alerts during a flash sale, you'll want the Eventstream path instead.
The data Fabric extracts from your visual is essentially the result set that renders the visual — a flat table with the fields in your visual, evaluated for the current filter context. If your visual has slicers applied, those filters are respected. If it's showing data for all stores, all stores flow through.
Once you're in the Reflex designer, the interface has two main panes. On the left, you have an explorer showing your Objects and their Triggers. On the right, you have the detail canvas where you configure properties and trigger logic.
The first thing Data Activator needs to know is what column identifies individual instances of the thing you're monitoring. In our store sales example, StoreID is the right choice. Click on your newly created object in the left pane, and in the configuration panel, set the Assign your data section to use StoreID as the object ID.
Once you set the ID column, Data Activator creates a separate tracking context for each unique value. You'll see a preview in the canvas showing the current values for each store.
Properties define what you're measuring. Your initial trigger setup will have already created one property based on the measure from your visual, but you can add more.
For each property, you configure:
For DailySalesTotal, you'd typically use "Last value" since the data source already gives you the current daily total. For a metric like TransactionCount where you might see incremental records, "Sum" would be appropriate.
Note
When pulling from Power BI visuals, you often see "Last value" used almost exclusively because your semantic model has already aggregated the data. The aggregation setting in Data Activator becomes more important when you're working with Eventstream data, where you're dealing with raw event records.
Click on the trigger node in the left explorer (it will be listed under your object). The trigger configuration panel gives you a condition builder with the following types of conditions:
Threshold conditions fire when a value crosses above or below a fixed number. "DailySalesTotal falls below 15000" is a threshold condition.
Percentage change conditions fire when a value changes by a certain percentage from a previous reading. "DailySalesTotal decreases by more than 20% from the previous evaluation" catches sudden drops without requiring you to know what the "right" absolute number is.
Enters a range / exits a range conditions fire when a value crosses into or out of a defined band. Useful for things like "alert me when response time is between 500ms and 2000ms — not too low to be suspicious, not high enough to be clearly broken."
Is equal to / is not equal to conditions work on categorical fields. You can trigger on a status field changing to "FAILED" or "CANCELLED."
For our store sales scenario, let's build a compound rule: alert when DailySalesTotal drops below $15,000 and we're past noon local time (implying the shortfall is structural, not just an early-day timing issue). Currently, Data Activator's visual builder handles single-condition triggers cleanly. For multi-condition logic, you'll use the Formula tab in the trigger configuration, which accepts a simple expression language.
The formula for our scenario would look something like:
DailySalesTotal < 15000
You can reference multiple properties in a formula by name, combine them with AND, OR, and use comparison operators. The language is intentionally simple — it's not DAX or KQL, but it handles the conditions you'll encounter in practice.
Warning
Data Activator triggers do not re-fire continuously while a condition remains true. By default, a trigger fires once when the condition becomes true (the transition from false to true) and won't fire again until the condition becomes false and then true again. This is almost always what you want — otherwise you'd get a flood of alerts every evaluation cycle. But it means you need to think about what "resolved" looks like in your scenario. If a store's sales never recover in a day, the trigger fires once in the morning and stays silent.
The trigger fires — now what? This is where Data Activator connects to the rest of the Fabric ecosystem.
The two simplest response types are Email and Teams message. Both are configured in the "Act" section of your trigger, accessible once you have a trigger defined.
For Email, you specify:
{PropertyName} syntax — for example, "Store {StoreName} has DailySalesTotal of {DailySalesTotal}, which is below threshold."For Teams, the setup requires your Fabric workspace to have a Teams connection configured. You specify a Teams channel or a direct message recipient, and the same dynamic message interpolation applies.
Both of these are fine for human-loop scenarios — situations where a person needs to investigate and decide. For automated remediation, you want the pipeline trigger.
This is where Data Activator becomes genuinely powerful. Instead of (or in addition to) a notification, you can configure a trigger to execute a Fabric data pipeline. This means your alert can automatically:
To configure a pipeline response:
{PropertyName} interpolation syntaxFor example, imagine you've built a pipeline called Reprocess_Store_Sales that accepts a StoreID parameter and re-runs the aggregation for that specific store from the raw transaction log. Your Data Activator response would pass {StoreID} as the parameter value, so the pipeline runs only for the store that triggered the alert.
Tip
Before wiring up a pipeline trigger in Data Activator, test your pipeline manually with the parameter values you expect to pass. A pipeline that fails silently due to a bad parameter is harder to debug through the Data Activator interface than it is in the pipeline designer itself. The Monitoring Hub will show you pipeline runs triggered by Data Activator, which is your primary debugging view for these automated runs.
This pipeline trigger capability makes Data Activator a legitimate orchestration signal, not just a notification system. Think of it as the "on-demand trigger" complement to your scheduled pipeline runs — your schedules handle routine operations, and Data Activator handles exception-driven operations.
For true real-time alerting — sub-minute latency on streaming data — you connect Data Activator directly to an Eventstream rather than a Power BI visual. This path is architecturally different and significantly more capable.
If you're not yet familiar with how Eventstreams work in Fabric, the real-time analytics overview covers the ingestion and routing model in detail.
Eventstreams in Fabric support multiple output destinations simultaneously. You can route the same stream to an Eventhouse for historical KQL queries and to Data Activator for real-time alerting in parallel — you don't have to choose.
To add Data Activator as a destination:
Once connected, the Eventstream will forward a copy of each event record to your Reflex. In the Data Activator designer, you'll now see the stream's schema available for mapping to properties.
This is where the Eventstream path differs most from the Power BI path. Your events are individual records with an event schema — not pre-aggregated visuals. You need to tell Data Activator:
device_id, sku_id, order_id)For a real-time inventory scenario, your events might look like:
{
"event_time": "2024-03-15T14:32:07Z",
"sku_id": "SKU-1042",
"sku_name": "Wireless Headphones Pro",
"event_type": "sale",
"quantity_change": -1,
"current_inventory": 47,
"warehouse_id": "WH-EAST-01"
}
You'd configure:
sku_idevent_timecurrent_inventory (last value), quantity_change (sum over window), event_type (last value)With this mapping in place, Data Activator maintains a running state for each unique sku_id as events flow through. When SKU-1042's current_inventory hits 47, then 46, then 45 — Data Activator is tracking that descent and will fire a trigger the moment it crosses your defined threshold.
Key insight
The aggregation setting on Eventstream-connected properties has real impact on trigger behavior. If you set quantity_change to "Sum" with a 5-minute window, your trigger on that property evaluates against the total quantity sold in the last 5 minutes — a velocity measure. If you use "Last value," you see the per-event change. These produce completely different trigger semantics, so be deliberate about your choice.
One of the most practical real-time patterns is a velocity trigger — not "inventory is low" but "inventory is dropping faster than expected." This catches situations before they become critical.
In the Data Activator trigger formula editor, you can reference the change over time of a property:
current_inventory < 100 AND quantity_change < -20
This fires when inventory is below 100 and more than 20 units have been sold in the last aggregation window — a sign that you're in a demand spike and will hit zero soon if you don't act.
You can pair this trigger with a pipeline response that automatically creates a purchase order record in your operational database, or that sends a priority notification to your procurement team's Teams channel with specific reorder details embedded in the message.
A mature monitoring setup won't have one trigger per Reflex — it'll have multiple triggers at different severity levels on the same object. Data Activator supports this naturally within the object-trigger hierarchy.
For a Product SKU object, you might define:
| Trigger | Condition | Action |
|---|---|---|
| Low Inventory Warning | current_inventory < 100 |
Teams message to procurement channel |
| Critical Inventory Alert | current_inventory < 20 |
Teams message + Email to head of supply chain |
| Out of Stock | current_inventory <= 0 |
Pipeline run: disable listing + notify ops |
| Demand Spike | quantity_change < -30 in 5 min |
Pipeline run: flag for expedited replenishment |
Each trigger is independent. The "Out of Stock" trigger firing doesn't suppress the "Critical Inventory Alert" — they evaluate independently. This is usually what you want: a cascade of escalating responses as the situation worsens.
Warning
Be careful about trigger interaction if your pipeline responses modify the same data that drives your properties. If the "Out of Stock" trigger fires a pipeline that resets current_inventory to -1 as a sentinel value, and your "Critical Inventory Alert" condition is current_inventory < 20, you may get an unexpected re-fire on the sentinel value. Design your pipeline responses with awareness of the feedback loop.
Before you activate a trigger in production, use the Preview functionality in the Data Activator designer. When you click Preview on a trigger, Data Activator shows you the historical event data it's received and highlights which time points would have caused the trigger to fire.
This is your primary validation tool. If you're testing with real data and the preview shows no firing events when you expected several, check:
Let's build a complete working example. You'll create a Reflex connected to a Power BI report visual, define an alert for stores underperforming against target, and configure it to both send a Teams notification and trigger a data pipeline.
Setup assumptions:
StoreID, StoreName, DailySalesTotal, and SalesTargetFlag_Underperforming_Store in the same workspace that accepts a store_id parameterSales_Monitoring_ReflexIn the Data Activator designer:
StoreStoreIDStoreName — this makes notifications human-readableYou should see a preview showing each of your stores as separate object instances.
Your raw data has DailySalesTotal and SalesTarget. You want to track the shortfall as a percentage. While Data Activator doesn't support complex derived properties natively, you can add a second property for SalesTarget and write your trigger condition to compare the two.
SalesTargetSalesTarget column from your dataStore object, click Add triggerBelow_Target_AlertDailySalesTotal < SalesTarget * 0.85
This fires when a store is more than 15% below its daily sales target.
Teams notification:
⚠️ Store Alert: {StoreName} (ID: {StoreID}) is underperforming.
Current sales: {DailySalesTotal}
Target: {SalesTarget}
Gap: Check the Sales Dashboard for details.
Pipeline trigger:
Flag_Underperforming_Store pipelinestore_id parameter to {StoreID}Trigger never fires despite condition being met
The most common cause is that the semantic model hasn't refreshed since you activated the trigger. Data Activator evaluates conditions only when new data arrives. If your model refreshes on a schedule, the trigger won't evaluate between refreshes. Confirm the model is refreshing on the expected schedule.
Also check that you're watching for the right transition. If the condition was already true when you activated the trigger, it may not fire until the condition becomes false and then true again. Testing with a condition you know will be triggered on the next refresh is the safest validation approach.
Trigger fires but pipeline doesn't run
Open the Monitoring Hub and check the pipeline run history. If the pipeline is listed with a failure status, look at the error details — the most common cause is a parameter name mismatch (your pipeline expects StoreID but Data Activator is passing store_id). Parameter names are case-sensitive and must match exactly.
Also verify that the identity running the Reflex (your account, or the workspace's managed identity) has permission to execute the pipeline. Workspace roles and permissions control this — you need at least Contributor access on the workspace containing the pipeline.
Getting flooded with repeated notifications
If you're seeing the same alert fire repeatedly for a condition that stays true across multiple refresh cycles, check the trigger's recurrence setting. There's a setting that controls whether a trigger can re-fire while the condition remains true. The default is "fire once per condition onset," but it may have been changed. Look for a setting like "Send notification each time condition is met" vs. "Send notification when condition changes to true."
Eventstream property shows wrong values
If your Eventstream-connected property shows values that don't match what you expect, check the aggregation setting first. A "Sum" aggregation on a field like current_inventory that contains absolute values (not deltas) will produce nonsensical results — it'll add up all the inventory readings in the window rather than taking the latest. "Last value" is correct for absolute measurements; "Sum" is correct for delta/increment events.
Object preview shows "No data"
This usually means the Eventstream connection isn't flowing data yet, or the field you've designated as the object ID has no values. Check that:
Note
Data Activator has a warm-up period when you first connect an Eventstream. It may take a few minutes before the preview shows data, even if events are flowing. Give it up to 5 minutes before concluding there's a configuration error.
Teams messages not delivering
Verify the Teams connection is authorized. When you first configure a Teams action, Fabric needs OAuth consent to post to Teams on your behalf. If the consent flow was interrupted or if your organization's Teams policies restrict application posting to channels, messages will silently fail. Check the trigger's activity log in the Data Activator designer — failed message deliveries should appear there.
Data Activator transforms your Fabric environment from a system that stores and displays data into one that actively responds to it. The three-layer model — objects, properties, and triggers — gives you a clean way to think about what you're monitoring, what you're measuring on it, and what conditions warrant a response. And by connecting responses to Fabric data pipelines, you're not limited to notifications; you can trigger real data operations automatically.
The Power BI path is the right starting point for teams who already have well-maintained semantic models and need alerting against business KPIs — store performance, pipeline SLAs, financial targets. The Eventstream path is for genuinely real-time scenarios: IoT telemetry, transaction streams, or any situation where 30-minute latency is too slow to be useful.
As you get more comfortable with Data Activator, a few natural next steps:
The goal isn't to create a system that sends more alerts — it's to create a system that takes the right action, automatically, so your team can focus on decisions that actually require human judgment.