How do Activator Alerts behave after deploying to different workspace

[flickeringflash]

I have multiple real-time dashboards, where those dashboards use an Application Insights Resource as a Data Source and a specific environmentID as a parameter.
Firstly we couldn't figure out how to change those datasources from TEST to PROD when using Deployment pipelines.

Secondly it seems as though when you set an alert on a dashboard tile, but change the tile's KQL query later it breaks Activator Alerts and those alerts trigger on the previous old KQL query.

What's the best practice when deploying dashboards to different workspaces. Is there a way to change alerts after deployment so those alerts notify different corresponding Teams chat groups (TEST ->PROD)?

Any help would be greatly apreciated or atleast an answer, because Microsoft Learn mentions nothing of that sort.

[flickeringflash]

Thank you for your response. Turns out that Real-time dashboard are not eligible for deployment rules. Do you have any other suggestions on what to use to make sure that dashboards use correct datasources?

It is a shame that we will have to recreate those alerts every single time we change those dashboards and deploy.

[v-tejrama · Accepted solution]

Hi  @flickeringflash ,

You’re right that real-time dashboards don’t support deployment rules, and that does limit how much of this process can be automated. In the current platform, those dashboards treat their data source connections as fixed endpoints, which means they don’t remap themselves when you promote content through a pipeline. The only dependable way to make sure they use the correct environment is to update the connection in the destination workspace after deployment. Some teams handle that manually while others script it using the REST APIs, but either way it has to happen outside the pipeline because the feature isn’t supported for this dashboard type.

The same limitation affects alerts. An alert attaches itself to the tile and the exact query that existed when it was created, so if the tile changes or you promote it into another workspace, the alert doesn’t update along with it. I know it creates extra work, but at the moment the only reliable method is to recreate the alerts in the target workspace as part of your deployment process. Automation can help streamline this if you prefer not to recreate them by hand.

Thank you for your continued efforts in testing the approaches we’ve provided. Since some time has passed and several options haven’t produced the results you need, it would be a good idea to raise a support ticket with the Microsoft product team so they can take a deeper look at what’s happening in your environment. You can submit a request through the Submit a product support request page:
Microsoft Fabric Support and Status | Microsoft Fabric

If you do end up finding a resolution through support, it would be incredibly helpful if you could share it back here with the community, as others facing similar challenges may benefit from it. We appreciate your patience and encourage you to keep engaging with the Fabric Community whenever you need further support.

Best Regards,
Tejaswi.
Community Support

[v-tejrama]

Hi @flickeringflash ,

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank you.

[flickeringflash]

Hi, 
You've been great so far. I do actually have one more question and that is if you can provide any more details about automation of the process like you mentioned earlier.

[v-tejrama]

Hi @flickeringflash ,

Thanks for reaching out about this. What you’re running into is expected behavior when working with Application Insights data sources and Activator Alerts across different workspaces. When a dashboard uses Application Insights, the connection is tied directly to that specific resource, so deployment pipelines don’t automatically update the connection from your Test to Prod environment. To handle this, you’ll need to configure your setup so that the data source or environment ID can be updated after deployment, often by using parameters and deployment rules to point to the correct Application Insights resource in each stage.

For the alert behavior, Activator Alerts are linked to the exact tile and query that existed when the alert was first created. If the KQL query or the dataset changes later, the alert doesn’t automatically refresh to match the new configuration. This can cause alerts to continue triggering based on the old query definition. The recommended approach is to recreate the alerts in the target workspace after deployment so that they’re connected to the correct tiles and queries. Many teams also set up different Teams channels or webhooks for each environment, which helps ensure that alerts from Test and Prod go to the right places.

In short, alerts don’t travel cleanly between environments and need to be recreated after each deployment. Setting up parameters for your data sources and managing alerts separately for each workspace will give you a more stable and predictable setup as you move content between Test and Prod.

Best Regards,
Tejaswi.
Community Support