tips and tricks
21 TopicsHow Do You Optimize KQL Queries for High-Volume Real-Time Analytics?
As real-time data volumes grow, keeping analytics queries responsive while maintaining low-latency insights can become challenging in Microsoft Fabric Real-Time Intelligence. I'm interested in learning how teams optimize KQL queries when handling continuous streams of high-volume events. A few areas I'd like to explore: Which KQL optimization techniques have the biggest impact on query performance? How do you manage high-cardinality columns and large event datasets? When should you use materialized views instead of querying raw event data? What strategies help maintain responsive dashboards during heavy ingestion workloads? I'd love to hear practical experiences, optimization techniques, and recommendations from teams working with Microsoft Fabric Real-Time Intelligence.17Views0likes3CommentsHow Are Teams Turning Real-Time Data into Automated Business Actions?
Real-time data is valuable, but its real impact comes from how quickly organizations can turn incoming events into meaningful business actions. With platforms like Microsoft Fabric Real-Time Intelligence, teams can monitor streaming data, identify important events, configure alerts, and respond to changing conditions. However, connecting these insights with actual business workflows remains a challenge. For example, organizations could automate operational notifications, trigger follow-up processes, route tasks to the right teams, and use AI-driven workflows to reduce manual intervention. I'm interested in understanding how different teams are approaching this. How are you using real-time events to trigger automated workflows? What challenges do you face with event detection, alert reliability, and downstream integrations? Are you combining real-time analytics with AI agents to support faster business decisions? For organizations exploring this broader approach, AI business automation solutions can help connect intelligent automation with everyday business operations. Would love to hear about practical implementations and lessons learned.34Views0likes3CommentsBest practice for handling schema evolution in Fabric Eventstream before data reaches Eventhouse?
I have an Eventstream receiving operational events where the schema may evolve over time. For example, the producer initially sends: DeviceId, Timestamp, Temperature, Status but later adds fields such as: Location, FirmwareVersion, ErrorCode I want the pipeline to continue ingesting events without breaking downstream KQL tables, update policies, materialized views, or Real-Time Dashboards. I am trying to understand where schema evolution should ideally be handled in a production Fabric RTI architecture. Would you: enforce the contract upstream using Schema Registry normalize changing fields inside Eventstream before Eventhouse ingestion land the raw payload first and handle schema evolution inside Eventhouse/KQL maintain separate versioned event schemas/tables How are people handling this in production when producers can add fields without notice? I am particularly interested in avoiding a design where every small upstream schema change forces updates across Eventstream, KQL tables, update policies, and downstream dashboards.Solved177Views0likes3CommentsAllow 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.85Views0likes2CommentsHow are teams combining AI agents with Microsoft Fabric Activator for intelligent automation?
I am exploring how AI agents can work together with Microsoft Fabric Activator to create more intelligent event-driven workflows. Traditional automation usually depends on predefined rules and thresholds, but AI agents could add more context and decision-making capabilities. Some possible scenarios: Detecting business events from real-time data streams Using AI to analyze the context behind an event Triggering workflows based on intelligent decisions Sending recommendations instead of only alerts Connecting Fabric data workflows with external APIs and business systems I would like to understand how developers are approaching this: Are you using Fabric Activator with Power Automate, APIs, or custom AI agents? What are the best patterns for handling complex event conditions? How do you manage accuracy and avoid unnecessary automation triggers? Would love to hear practical examples or architecture approaches from the community.Solved75Views0likes4CommentsWorking with Microsoft Fabric Support - A Collaborative Approach
At Microsoft Fabric Support, our goal is simple: help you resolve issues as quickly and smoothly as possible. Just like the recommendations shared in the Microsoft Fabric Community’s guidance on getting questions answered effectively, providing clear and complete information upfront helps everyone move faster and avoid unnecessary back-and-forth. Support is most effective when it’s a collaborative process. You bring the knowledge of your environment and workloads, and we bring deep platform expertise and diagnostics to help investigate the issue together. Help Us Help You When opening a support case, please include as much of the following information as possible: Issue Details Clear description of the problem Expected behavior vs. actual behavior Is the issue intermittent or consistently reproducible? Approximate timeframe of when the issue occurred (UTC preferred) Error Information Please include: Full error message text Screenshots (highly recommended) Activity IDs / Correlation IDs if available Even small details can significantly speed up investigation. Environment Information That Helps Investigation Depending on the Fabric workload being used, please provide the relevant item IDs and environment details. Workspace Information Workspace ID / Workspace URL To find this: Open the Fabric workspace Copy the URL from your browser Example: ".. https://app.fabric.microsoft.com/groups/<WorkspaceID>/… …" The value after /groups/ is the Workspace ID. Screenshot example above showcases the WorkspaceID and EventhouseID. Fabric Item IDs Please provide the item ID related to the affected workload, such as: EventhouseID ActivatorID LakehouseID WarehouseID SemanticModelID EventstreamID PipelineID These IDs help us locate telemetry and backend diagnostics more efficiently. You can typically find these: In the browser URL while inside the Fabric item Within item settings/details pages From the Fabric portal navigation pane Additional Environment Details Please also include: "… WorkspaceID: Capacity Name: Region …" Example: "… WorkspaceID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Capacity Name: Fabric-Prod-EastUS Region: East US …" This information helps us identify: Capacity-level issues Regional service impact Configuration-specific behavior Why This Matters Microsoft Fabric is a distributed cloud platform, and troubleshooting often depends on correlating logs, telemetry, timestamps, and resource identifiers together. Providing complete details upfront helps: Reduce delays Avoid repeated clarification requests Accelerate root cause analysis Create a smoother support experience for everyone involved We’re here to partner with you throughout the process, and we truly appreciate your collaboration in helping us investigate issues effectively. We look forward to working with you!1.2KViews5likes3CommentsRTI Event Metadata Table Use Cases
Hi everyone, I’m looking to expand how others are using metadata tables in Microsoft Fabric RTI architectures. Current state We have an IaC-driven deployment process that provisions RTI assets from source → bronze → silver. As part of this deployment, we persist configuration and lineage information into a metadata table stored in SQL DB. At a high level, the metadata schema includes: EventTopic SourceObjectSettings (JSON) – bronze/silver table names, flatten function, etc. TopicInformation (JSON) – topic-level semantics Audit columns (create/modify user + timestamps) The metadata is written at deploy time and represents the intended RTI topology. Current primary use case: Bronze → Silver reprocessing Our main use case today is controlled reprocessing from bronze to silver. Since Fabric update policies only apply to data in motion, when we need to: fix a flattening bug handle schema changes correct downstream logic we need a way to deterministically replay historical data. To support this, I built a parameterized pipeline that accepts: EventTopic StartTime EndTime The pipeline triggers a fully parameterized notebook that: Uses the provided EventTopic to query the metadata table Retrieves the associated flatten function, bronze table, and silver table Dynamically builds the KQL query Reprocesses bronze data for the specified time window into silver This approach avoids hard-coded topic logic and has worked well so far. What I’m looking for I’m interested in learning how others are extending this metadata-driven pattern beyond reprocessing, particularly in larger RTI platforms. What other valuable use cases have you found for metadata tables in RTI architectures? Any lessons learned or pitfalls would also be appreciated. Thanks in advance.Solved7.2KViews2likes4CommentsHow do Activator Alerts behave after deploying to different workspace
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.Solved4KViews0likes5CommentsAzure resource graph and KQL
Hi Everyone, I am trying to find the right data for compute resources (ex -Virtual machine allocated cores versus used cores for all the subscribtions and quite other things allocation and usage ) . I need to use kusto explorer/ ADX for analyzing this data. I cannot run queries in azure portal for same. The kql returns data in json format. The challenge is ARG, kusto, kql. All these 3 things are new to me. So how do I start to identify the infrastructure compute data allocated, used and write queries that could be used in reporting tools.Solved10KViews0likes2Commentshow to log the data which is triggering alert in data acyivator
Logging and tracking of alaram events for post-analysis and system improvements I'm working with Microsoft Fabric's Data Activator to monitor real-time device temperatures. My goal is to implement a solution that does the following whenever a temperature exceeds a predefined threshold: Trigger an Alert: Send an email notification to the relevant stakeholder when the threshold is crossed. Log Alarm Data: Write the event into two separate Lakehouse tables: alarm_event_log: stores the actual telemetry data that caused the alarm. alarm_metadata: stores metadata about the alarm (timestamp, severity etc.). Execute Logging via Notebook: Use the "Action" section of the Data Activator rule to trigger a Fabric notebook that logs this data into the Lakehouse. (in action i am using fabric item which is notebook) What I need help with: How can I retrieve the data from Data Activator in the triggered notebook? Specifically, how do we access the relevant data (e.g., device ID, temperature reading, time of alert) that triggered the rule, and then pass or retrieve it within the notebook to log it properly? so like is there any way to retrieve that particular record from activator which caused the alert, if yes then how to implement it, I am planning to write the pyspark script for it, but little confuse about the logic What are the best practices or recommended methods for passing parameters from Data Activator to a Fabric notebook? Has anyone implemented a similar pattern? Any sample implementation or guidance on structuring this kind of workflow for reliability and scalability would be very helpful. Thanks in advance for your support!Solved6.3KViews0likes8Comments