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.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:
