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.Microsoft Fabric Activator generating repeated false alerts despite stable Power BI metric
Hi! I'm experiencing an issue with Microsoft Fabric Activator that started last week after working reliably for several months. I have several Activator alerts monitoring Power BI metrics that indicate whether data for the previous day is available. After the daily semantic model refresh, the metric correctly changes from FALSE (0) to TRUE (1) once yesterday's data is available. The problem is that after the refresh has completed, the report/dashboard remains stable, but Activator continues to fire the alerts repeatedly. What I observe The semantic model refreshes successfully. The Power BI report/dashboard correctly shows TRUE (or 1) and does not change afterwards. The semantic model is not refreshed again for several hours. However, the Activator PowerBI Metric live feed repeatedly alternates between TRUE/FALSE (or 1/0) for some monitored objects, even though the report values remain unchanged. Since my alert is configured as "Changes to TRUE", these false state changes cause repeated alert notifications. Expected behaviour The semantic model refreshes. The metric changes from FALSE to TRUE once. Activator triggers a single alert. No further alerts are generated until the metric actually changes again. Actual behaviour The semantic model refreshes successfully. The report/dashboard values remain stable. The Activator PowerBI Metric live feed shows alternating TRUE/FALSE (or 1/0) values. Alerts continue to fire despite no changes to the underlying data. Troubleshooting performed Confirmed the semantic model had not refreshed again. Confirmed the report/dashboard values remained unchanged. Confirmed the alert definition had not been modified. Deleted and recreated the Activator alerts. Replaced numeric 1/0 measures with Boolean TRUE/FALSE measures. The issue persists after all of the above. Has anyone else experienced similar behaviour recently? Is this a known issue with Fabric Activator or the PowerBI Metric event source? Thanks in advance!Enable configurable recipients for Activator error notifications - critical for monitoring
According to the official documentation: "If a problem occurs with any of your Fabric Activator events, objects, or rules after you create them, then Fabric Activator sends you an email containing an error code." However: The recipient is not configurable (hardcoded to item creator only) This limitation is not documented No alternative notification channels are available This creates a critical blind spot for production monitoring when: Activators are deployed via service principal (cannot receive emails) The original creator leaves the team or changes roles Multiple team members need visibility into system errors Requested Feature: Enable configuration of error notification recipients through: Workspace-level notification settings Distribution list/group email support Integration with workspace contacts/admins Use Case: Our production Activators are deployed via CI/CD pipelines using service principals. Without configurable notifications, we have no way to receive critical error alerts, making Activator unsuitable for production use
Fabric known issue ID 1719
Hello, I am referring to Fabric known issue ID 1719: we have implementend activator alerts sending emails with context properties as parameters; we are using and do require the 'when it has been true for' condition in these alert rules. We want to move our solution to production, but unfortunately this is not possible with faulty emails where parameters are not rendering. Does anyone know when a fix for this issue can be expected? Tnx in advance and best, flo.Not able to creat alert over a table chart without removing columns
I've been creating alerts on a table chart based on different filtering, however it stopped allowing me to create alerts on that table since 3 days ago, as a test I removed all the alerts previously created and now I cannot create any new alert over that table chart. I tested by removing columns and that is the only way i'm able to create alerts again on that table chart card, then republishing the report adding the deleted columns. With all the columns I'm able to select the column to base the alert but after that, the alert it is not created, and I'm not able to proceed:
