📉 How Would You Investigate a 20% Drop in Revenue?
A data analyst shouldn’t stop at identifying what happened. The real questions are: Where did the decline occur? → Why did it happen? → What caused it? → What should we do next? By analyzing regions, products, customers, time periods, and key business metrics, raw data can reveal the root cause behind the numbers. Good data analysis turns numbers into decisions. 📊 #DataAnalysis #BusinessIntelligence #PowerBI #MicrosoftFabric #DataAnalytics
Expose Real-Time (KQL) Dashboard Usage Through Activity Events and Audit Logs
Microsoft Fabric currently inventories Real-Time (KQL) Dashboards, allowing administrators to discover and manage them through inventory metadata and workspace scanning. However, there is no corresponding dashboard usage telemetry available through the Activity Events API, Audit Logs, or related admin monitoring capabilities. As a result, administrators can identify that a KQL Dashboard exists, but cannot determine whether it is being actively used. These questions can be answered today for many Fabric assets through activity and audit telemetry, but not for Real-Time (KQL) Dashboards. Administrators therefore have no reliable way to measure dashboard adoption or justify ongoing operational support. Requested Enhancement Add dashboard-level telemetry for Real-Time (KQL) Dashboards and expose it through: Fabric Activity Events API Fabric Audit Logs Admin APIs Future monitoring accelerators such as FUAM For example, Fabric Unified Admin Monitoring (FUAM) already consumes Activity Events and inventory metadata. If KQL dashboard view events were available, administrators could immediately report: Total views Unique viewers Last viewed date Adoption trends Most-used dashboards without requiring additional pipelines or custom data collectionMake Eventgrid Namespace MQTT broker part of Fabric
In Azure, this plain MQTT broker is offered as part of the Event Grid Namespace. Technically, this is a great broker, but it lacks usability because the UX in the portal is designed by a spartan. You just fill in the topic and authentication settings and pray it works out as expected with all the logic. Competitors have a nice UX and monitoring experience. With Fabric, why not expose an MQTT broker? Give it a nice UX to fill in topics, topic spaces, clients, client groups, permissions, and monitoring. Integrate it with eventstream as a source (on certain topics) and a destination (again with certain topics).
Get data from Apache Kafka topics via private networking
Current prerequisites limit to public Kafka instances which is not feasible for most enterprise customers. When will this limitation be lifted so that it can be used in private network setups, for example via gateway? https://learn.microsoft.com/en-gb/fabric/real-time-intelligence/event-streams/add-source-apache-kafka#prerequisitesAdd Schema Compatibility Policies and Breaking-Change Detection to Fabric Event Schema Registry
Fabric Event Schema Registry should support configurable schema compatibility policies so teams can safely evolve event contracts without breaking downstream Eventstreams, Eventhouse ingestion, applications, or other consumers. Today, schemas can be versioned, but compatibility enforcement is not yet available. This means producers can introduce changes that may unexpectedly break existing event-processing flows. Fabric should allow teams to define compatibility rules at the schema-set or individual-schema level. Requested capabilities should include: Backward compatibility Forward compatibility Full compatibility No-compatibility mode for intentionally breaking changes Automatic validation before a new schema version is published Clear identification of incompatible field additions, removals, type changes, and structural changes Breaking-change warnings Dependency and impact analysis showing which Eventstreams, Eventhouse tables, destinations, and applications use the affected schema Side-by-side schema diff between versions CI/CD validation API so compatibility checks can run before deployment Approval workflow for intentionally breaking changes Ability to mark older schema versions as deprecated with an effective retirement date For example, if a producer changes a field from integer to string, removes a required property, or changes a nested structure, Fabric should immediately show whether the new version is compatible with existing consumers before the schema is activated. The experience should also show exactly which downstream artifacts may be affected by the change. This would turn Event Schema Registry into a true enterprise contract-management capability rather than simply a centralized place to store schema versions. It would significantly reduce production failures caused by unexpected schema evolution and make Fabric Eventstream safer for large-scale real-time and event-driven architectures.Add Incremental and Event-Driven Refresh for Fabric IQ Ontology
Fabric IQ Ontology should support incremental and event-driven updates when the underlying source data changes. For operational and real-time scenarios, ontology entities and relationships may be backed by Lakehouse, Eventhouse, semantic models, or other Fabric data sources that change frequently. Fabric should not require users to manually refresh or rebuild large portions of the ontology simply to make changed source data available. Fabric IQ should automatically identify which entities, properties, and relationships are affected by source-data changes and update only the impacted portions of the ontology. The capability should include change-aware incremental refresh, Eventstream-triggered refresh, pipeline-triggered refresh, configurable freshness targets, entity-level refresh status, last-successful-update timestamps, failed-record diagnostics, dependency-aware refresh ordering, and monitoring of refresh processing and capacity consumption. For example, if the status of an Asset, Work Order, Shipment, Customer, Device, or other operational entity changes, Fabric IQ should be able to update the relevant ontology state quickly without requiring a full ontology refresh. This would make Fabric IQ significantly more practical for operational intelligence, Digital Twin scenarios, Real-Time Intelligence, and AI agents that depend on current business context.Eventstream MQTT broker source: V3.1.1 support
The Eventstream MQTT broker source supports connections with public MQTT brokers that offer MQTT V5 support. Please offer support for V3.1.1 too, because this is still a valid and widely used version (perhaps still even more than V5). Regarding version V3.1 (which is different from V3.1.1), this one seems to be deprecated by now.Improve CI/CD consistency for Microsoft Fabric Real-Time Intelligence Eventstreams
Microsoft Fabric Real-Time Intelligence has made strong progress with Git integration and deployment pipelines, but lifecycle management can still be inconsistent across Eventstream sources, destinations, connections, and deployment scenarios. I would like to see more consistent CI/CD support across Real-Time Intelligence artifacts, including automated environment-specific connection rebinding, easier promotion from development to test and production, deployment validation before activation, and clearer diagnostics when an RTI artifact cannot be promoted successfully. For enterprise implementations, it would also be valuable to reduce the amount of manual reconfiguration required after deployment. Improving these capabilities would make Real-Time Intelligence solutions easier to operationalize, govern, automate, and teach as production-ready architectures rather than solutions that require manual configuration between environments.
RLS mismatch when assigning multiple regions in semantic model live connection.
Hello Community, I am facing an issue with Row-Level Security (RLS) in a Power BI report connected to a semantic model (live connection). I created RLS roles based on region-wise access. When I assign a user access to a single region (e.g., Brazil), the data displays correctly. However, when I assign the same user access to an additional region, the data for the first region starts showing mismatches. The formulas are correct, and the user has all required data permissions. Interestingly, if I give the user Contributor or Admin access at the workspace level, they can see all regions correctly. But the requirement is that the user should only have Viewer access, not workspace-level permissions. Has anyone faced this issue before? Is there a way to fix this so that users with Viewer access can see multiple regions correctly without needing workspace-level roles? Thanks in advance for your guidance!
