tips and tricks
18 TopicsBest 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.Solved96Views0likes2CommentsWorking 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.1KViews5likes3CommentsRTI 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.1KViews2likes4CommentsHow 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.Solved3.9KViews0likes5CommentsAzure 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.Solved10KViews0likes2CommentsMicrosoft Fabric Known Issues
Known issues are temporary bugs that we've discovered in Microsoft Fabric. These bugs are known and are being actively fixed. Before you submit a Support request, or search Community forums for an answer, see if the problem that you're experiencing is already known to Microsoft. There are two locations to look up current known issues: Known issues as a list on Learn Known issues page on the Fabric support site For service level outages or degradation notifications, check https://support.fabric.microsoft.com/. To create a support ticket, visit https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket.6.3KViews0likes1Commenthow 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.2KViews0likes8CommentsHow to Make Data Activator Trigger Only Once Per Day Without Modifying Power BI?
Hi Fabric Community, We have a Power BI dashboard that tracks error counts, and we want to set up Data Activator to trigger an alert only once per day when errors occur. However, our Power BI dataset refreshes at irregular intervals, and Data Activator checks the dataset every 3600 seconds (1 hour) by default, which can cause multiple alerts. We don’t want to modify the Power BI table (e.g., adding flags or timestamps) use Power Automate. Is there any setting in Data Activator itselft that allows us to limit the trigger frequency to only once per day? Would adjusting “When it has been true for N times”, “Number of times”, help in ensuring only one alert is fired per day regardless of Power BI refresh timing? Thanks in advance for your help!Solved5.4KViews0likes4Comments