Allow multi-column conditions/output in Power BI Activator rules (Power BI visual-based alerts)
Description: When I create an Activator alert from a Power BI report visual, the rule can only evaluate the single column or measure it was created from, and the alert can only reference that same value. This blocks common governance and monitoring scenarios. Example scenario: I wanted an alert for Dev workspaces that sit on a billable (Premium/Fabric) capacity. That needs a condition on both Workspace Name (contains “Dev”) and Capacity/Billing type (not blank). Activator can’t combine the two in one rule, so I had to build the alert in Power Automate with a DAX query instead. Limitations: A condition can use only one column or measure, with no AND/OR across several attributes. The alert message or action can include only that same column. I can’t add related details like workspace name, dataset link, or owner. There’s no way to run a DAX query as the rule logic. Requested improvements: Conditions across multiple columns/measures (AND/OR). Selectable output fields, so the Teams or email action can include several columns, and dynamic links. Optionally, the ability to define the trigger with a DAX query, as the Power Automate “Run a query against a dataset” action does.
New Power BI alert in a new Activator item shows “version not supported”
I’m seeing an unsupported-version warning on an alert I created today from a Power BI report visual. I created a new Activator item for it, selected a field as the row identifier, chose email notification, and applied the alert. When I open the new Activator item, the event says: “This event is in a version that is currently not supported. Displaying it in a view only mode.” The alert rule showed the same warning. This is not an old rule I’m trying to edit. Three alerts I created last week do not show this warning. Is this a known issue or recent change? Does the rule still run in view-only mode, and is there a supported fix? I can share redacted screenshots if helpful.
Unable to see PowerBI Activator Alerts
I think I created an alert as a test and now I'm getting daily alerts in Teams from Activator. I tried to turn the rule off, but the link takes me to a Power BI app space I don't use, and I just see an error message. I tried to stop the Teams messages by deactivating the bot and now I get daily emails from Activator. I don't see any rules on the report that I made the test alert on either. How do I turn this off? One day I might actually want to use Activator alerts but I can't even manage them right now....and I work at Microsoft
Fabric Business Events: what delivery guarantees and replay pattern should we design for?
Hi all, I am testing the newer Business Events capability in Fabric Real-Time Intelligence and trying to understand what reliability assumptions should be made for a production design. The pattern I am looking at is roughly: Eventstream → Business Event → Activator → downstream action / User Data Function with Eventhouse enabled so the published business events are also retained for historical analysis. The current documentation explains the publisher/consumer model and shows how Eventstream can publish a governed business event that Activator then consumes. What I have not been able to find clearly documented is the delivery contract between the published business event and its consumers. A few things I am trying to clarify: If an Activator consumer or downstream action is temporarily unavailable, does Fabric retry delivery of the business event? Should consumers assume at-least-once delivery and therefore be designed to handle duplicate events, or is a different delivery model used? Is event ordering guaranteed in any scope, for example for events from the same Eventstream publisher? Since published business events can also be retained automatically in Eventhouse, is that retained history intended to support replay/reprocessing after a consumer outage, or is it primarily an analytical record and replay would need to be implemented separately? Are there documented retry or delivery-retention windows that should be considered when designing an operational workflow? I am mainly trying to understand what a resilient production pattern should look like when the business event triggers something with side effects, where processing the same event twice or silently missing an event would matter. Would you generally make the downstream consumer idempotent and treat Eventhouse as an audit/recovery store, or is there a more Fabric-native pattern for this? Interested to hear how others are approaching this with Business Events and Activator.
Activator + Fabric deployment: Not possible to parametrize triggered pipelines.
Disclaimer: I used ChatGPT to help me compile the message, but the problem itself was found and tested by me. I’m seeing inconsistent behavior when deploying Activator items across Fabric deployment pipeline stages. Scenario We have a standard three-stage setup: DEV workspace TEST workspace PROD workspace Each workspace contains: a Lakehouse used as the event source an Activator item a Fabric Pipeline used as the action target The intended flow is: A folder/file is created in the Lakehouse. Activator receives the OneLake/Lakehouse event. Activator triggers the Pipeline in the same workspace/stage. So the expected behavior is: DEV Lakehouse event → DEV Activator → DEV Pipeline TEST Lakehouse event → TEST Activator → TEST Pipeline PROD Lakehouse event → PROD Activator → PROD Pipeline UI confusion Firstly, the Activator UI can show the action target workspace as if it is correct. However, runtime behavior shows that the underlying workspace/item references are not consistently remapped. I also found a difference depending on how the rule is authored: If I create the activation rule from the Pipeline side, Fabric creates an event/action configuration that appears to remap correctly during deployment. So the Activator in DEV workspace points to pipeline in DEV workspace, and rhe Activator in TEST workspace points to same pipeline in TEST workspace If I create an equivalent rule directly from the Activator UI, the workspace text in Action-Fabric item is not changing after deployment. So the Activator in DEV workspace points to pipeline in DEV workspace, and rhe Activator in TEST workspace also points to pipeline in DEV workspace. However, when event happens, the pipelines are executed in different workspaces. So two visually similar Activator rules appear differently in the UI, while behaving the same way. Activator content At first, I created one event. But then I found out, that event source cannot be remapped during deployment. So DEV Lakehouse will always be a source for the event in all 3 workspaces. Therefore, to test how Activator behaves across stages, I created one event for each physical Lakehouse: DEV, TEST, and PROD. The expectation was not that the event source itself would be remapped, but that the action target would remain correctly associated with the corresponding Pipeline for that event/stage. Observed behavior I created a test Activator containing three events/rules: one for the DEV Lakehouse, one for the TEST Lakehouse, and one for the PROD Lakehouse. Each event/action was intended to trigger the corresponding Pipeline in the same workspace. After deploying the Activator, Pipeline, and Lakehouse through the deployment pipeline, the runtime behavior was inconsistent: Creating a folder in the DEV Lakehouse triggered three pipeline runs, one in each workspace. Creating a folder in the TEST Lakehouse triggered three pipeline runs, two in TEST and one in PROD. Creating a folder in the PROD Lakehouse triggered three pipeline runs, all in PROD. This creates a serious CI/CD risk. If an Activator definition contains event sources from multiple stages, those source subscriptions appear to remain fixed after deployment. Then, depending on how action targets are autobound, a single Lakehouse event can trigger multiple deployed Activators and run Pipelines in unexpected workspaces. For example: a DEV Lakehouse event can trigger TEST or PROD processing a TEST event can trigger PROD processing multiple deployed Activators can react to the same physical OneLake event This is not safe for deployment pipelines. Rule conditions and parameters cannot solve the issue at the moment I tried to use Activator rule conditions/action parameters to guard against this. However, all available fields appear to come only from the source event payload: source subject time id type data.url data.blobUrl data.requestId data.clientRequestId I do not see any way to reference: current Activator workspace current Activator item ID current deployment stage target action workspace target Pipeline workspace Fabric Variable Library values Because all deployed Activators that subscribe to the same physical OneLake event see the same event payload, rule conditions cannot distinguish “this Activator belongs to this workspace” unless some environment-specific value is manually patched after deployment. Same for the triggered artifacts - they have no idea which Activator (DEV, TEST or PROD) was used for triggering. Suggested fix from Microsoft Making Activator event/action references deployment-safe. Either by adding deployment rules to Activator class, exposing more runtime context to the Activator, or making triggered artifacts aware about Activator itself. Also, the Activator UI should not show an apparently correct target workspace if the runtime binding is different. Current workaround The only safe workaround I can see is to avoid deploying similar Activators altogether, or patch Activator references after deployment. I would glad if someone could offer another solution to this problem of mine.
