Activator basic concepts
Use this article to familiarize yourself with some of the terms and concepts associated with Fabric Activator (Activator). Understanding these terms and concepts makes it easier for you to read through the other Activator articles and to work with Activator.
There are many objects and concepts that make up Activator, too many to cover in a single article. So this article introduces you to the most common: activators, workspaces, eventstreams, rules, objects, events, and latency.
Activator creation workflow
A typical Activator workflow involves many of these concepts. One common workflow starts with creating a new empty activator in a workspace and using Get events to connect to an eventstream. From that eventstream, you create objects and properties. Then you build a rule based on those objects and properties. For example: email me if the temperature of the package becomes greater than 60 degrees. To create a rule on that object, the designer sets conditions, parameters, and aggregations that tell Activator when to trigger and what actions to take when triggered. For example: send an email, create a Fabric item, or start a Power Automate action. Another common workflow is to start from the eventstream itself. From the eventstream, you add an Activator destination and create the new activator. Once the activator is created, open that activator and create the objects and properties.
Workspaces
As with all Fabric workloads, you can begin using Activator by creating an item in a Fabric workspace. Activator’s items are called activators. Workspaces are places to collaborate with colleagues on specific content. Workspaces hold collections of dashboards, reports, eventstreams, activators, and more. When a workspace owner gives you access to a workspace, they also give you view or edit permissions to the content in that workspace. This access includes giving you permissions to view or edit the activator rules in that workspace.
Everyone also has a My workspace. My workspace is your personal sandbox where you create content for yourself.
To see your workspaces, select Workspaces from your left navigation pane.
Activator and activator
Activator is the name of the Fabric product. An activator is the thing that you create by using Activator. An activator holds all the information necessary to connect to data, monitor for conditions, and act. You typically create an activator for each business process or area you monitor.
Once you create an activator, populate it with data. Learn how to get data into your activator from Power BI, eventstreams, and Real-Time Hub.
Events and eventstreams
Activator considers all data sources to be streams of events. An event is an observation about the state of an object, with some identifier for the object itself, a timestamp, and the values for fields you’re monitoring. Eventstreams vary in frequency. IoT sensors might have events many times per second. While packages being scanned in and out of shipping locations might have sporadic streams.
An eventstream is an instance of the Eventstream item in Fabric. The eventstreams feature in the Microsoft Fabric Real-Time Intelligence experience lets you bring real-time events into Fabric, transform them, and then route them to various destinations without writing any code (no-code). Activator takes actions on patterns or conditions that are detected in eventstream data. For example, Activator monitors eventstream items and detects when an "event" hits certain thresholds such as "delivery time more than 10 hours." It then automatically takes appropriate action such as alerting users or kicking off Power Automate workflows.
Data being observed from Power BI is also treated as an eventstream. In this case, events are observations made of the data on a regular schedule that typically matches the refresh frequency of your Power BI semantic model (previously known as a dataset). These observations might only happen once a day, or even once a week – it’s just a slowly changing eventstream.
Objects
The business objects that you want to monitor could be physical objects like freezers, vehicles, packages, and users. The business object can also be a less tangible concept like advertising campaigns, accounts, and user sessions. In your activator, you model the object by connecting one or more eventstreams, choosing a column for the object ID, and specifying the fields you want to make properties of the object.
The term object instance refers to a specific freezer/vehicle/package etc., where object is typically used for the definition or class of object. We use population to refer to all of the object instances.
Rules
Rules define the conditions you want to detect on your objects, and the actions that you want to take when those conditions are met. A rule on a freezer object might detect the freezer being too warm, and send an email to the relevant technician.
There are three types of rules: rules on events, rules on events that are added to an object, and rules on an object's properties.
When a rule’s conditions are met, and an action is initiated, then the rule is activated
Properties
Properties are useful when you want to reuse logic across multiple rules. You might define a property on a freezer object that smooths out the temperature readings over a one-hour period. You can then use that smoothed value in many other rules.
Lookback period
Activator needs to track historical data to ensure that correct actions can be computed. The amount of historical data to be queried is called the lookback period. This lookback period depends on how a rule is defined and the data volume (events per second) of the data that is needed to evaluate the rule.
For example, a pharmaceutical logistics operation is transporting medicine packages in a cold chain. The goal is to get an alert when a medicine package becomes too warm. Say the rule definition evaluates the average temperature over a three-hour period for each individual package. And the rule condition is that the average temperature becomes greater than 8°C. Here, the lookback period is six hours. Activator needs to inspect six hours’ worth of historical data to decide whether the rule condition holds.
Distinct, active object IDs
Rules built on attributes are used to monitor how an attribute on an object ID changes over time. In the pharmaceutical logistics example, each individual package is represented by a unique ID. The data source provides periodic readings of the temperature of each package. Some limits are defined in terms of the number of distinct object IDs (the number of packages) being tracked by Activator within the lookback period. Activator tracks active object IDs. An active object ID is an object where events are arriving within the stored period. For example, a toll station that has cars passing through.