Add an End-to-End Production Reference Architecture for Microsoft Fabric Real-Time Intelligence
I would like to see a complete end-to-end Microsoft Fabric Real-Time Intelligence reference architecture that demonstrates how the individual RTI capabilities work together in a production-oriented solution. A manufacturing or operational telemetry scenario could show the complete flow from Eventstream through Eventhouse and KQL, Real-Time Dashboards, Activator, Power BI, Fabric Data Agents, and other applicable Microsoft Fabric capabilities. The guidance should explain architectural responsibilities, latency and retention choices, schema evolution, replay, security, governance, monitoring, CI/CD, environment promotion, connection management, and troubleshooting. It would also be valuable to explain when deterministic KQL queries, rules, or Activator actions should be used before introducing AI or agent-based processing. This would help architects, developers, students, and community learners understand how to move from individual Fabric RTI features to a governed and production-ready real-time solution.
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!
Allow Bookmarks to Affect Multiple Report Pages
Description: I would like to request the ability for a single Power BI bookmark to affect and maintain a state across multiple report pages, rather than being limited to a single page. For example, a bookmark could simultaneously apply filters, slicers, visual visibility, or other supported bookmark states across several pages of the same report. This would be particularly useful when creating different report views or user scenarios. For example, selecting an "Executive View" bookmark could automatically apply the predefined state across the Overview, Sales, Operations, and Finance pages. This functionality would make bookmarks more powerful for multi-page report navigation and scenario-based reporting, while reducing the need to create and maintain separate bookmarks for each page. Requested enhancement: Allow a single bookmark to store and apply supported bookmark states across multiple report pages within the same Power BI report.
Activator needs deployment safe context to prevent cross stage and cross workspace event triggering
Activator event sources, for example a Lakehouse OneLake event, are not remapped during deployment pipeline promotion. An event source always points to the original physical item, for example the DEV Lakehouse, even in the TEST or PROD copy of the Activator. This is expected behavior, but it creates a serious problem when combined with action target autobinding. Because multiple deployed copies of the same Activator, DEV, TEST, PROD, can all remain subscribed to the same physical source event, a single event, for example a folder created in the DEV Lakehouse, can cause multiple Activators across multiple stages to fire simultaneously, each triggering its own action target. In testing, a single DEV Lakehouse event caused pipeline runs in DEV, TEST, and PROD workspaces at once, with no isolation between stages. Attempting to guard against this using rule conditions or action parameters is not currently possible, because the only fields available in the rule condition are drawn from the source event payload: source, subject, time, id, type, data.url, data.blobUrl, data.requestId, data.clientRequestId. None of these expose: the current Activator's workspace or item ID the current deployment stage the resolved action target workspace or pipeline Fabric Variable Library values As a result, there is no supported way for a rule to determine whether an event belongs to its own stage and suppress execution if not. Downstream, the triggered Pipeline also has no way to know which Activator or stage invoked it. Requested fix: Make Activator event and action bindings deployment safe, for example by: Exposing runtime and deployment context, current workspace, deployment stage, item ID, and or Variable Library values, as usable fields in rule conditions and action parameters, and or Adding a dedicated deployment rules mechanism to the Activator item type, similar to other Fabric items, so event source and action bindings can be explicitly scoped per stage, and or Passing Activator and stage identity into the triggered Pipeline's run context so downstream items can validate or log which Activator instance triggered them. Without this, deploying Activator items across a standard DEV TEST PROD pipeline is unsafe, since a single physical event can fan out and trigger production processing from a non production event.Activator UI shows incorrect action target workspace after deployment pipeline promotion
When an Activator rule's action target, for example a Fabric Pipeline, is deployed across deployment pipeline stages, DEV to TEST to PROD, the Activator UI does not reliably reflect the actual runtime binding of that action. Specifically: If a rule is authored from the Pipeline side, the action target is correctly remapped per stage, and the UI accurately shows this. If an equivalent rule is authored directly from the Activator UI, the workspace reference shown for the Fabric item action does not update after deployment. It continues to display the source stage workspace, for example DEV, even in the TEST or PROD Activator. However, at runtime, the pipeline does execute in the correct per stage workspace. This means two rules that look functionally identical in the authoring UI behave differently under deployment, and in one of those cases the UI is actively wrong about what will happen at runtime. This is dangerous in CI CD scenarios because an admin reviewing a promoted Activator item cannot trust the UI to confirm which workspace or pipeline will actually be triggered. Requested fix: Ensure the Activator UI always displays the actual resolved action target workspace and item post deployment, regardless of which surface, Activator UI or Pipeline UI, was used to author the rule. If the underlying binding cannot be reliably shown, the UI should indicate that the reference is ambiguous or unresolved rather than showing a stale or incorrect workspace.Fabric Activator: detect "no change" as trigger
Hi, With Activator, it's possible to set alert based on trigger. These triggers are based on KPI values. Currently we can create triggers based on change detection. Eg: if the KPI value change, trigger a specific action. It could be very interresting to have the "no change" option. Eg: if my date/time doesn't change between two refreshes, trigger an action (send me a mail).Alerting on report KPIs using Activator in DirectQuery mode
Hi, It's wonderfull to use Activator to set alerts on PBI report KPIs (in card for exemple) but it only works by refreshing your dataset. In DirectQuery, we can see immediatly the change on KPI value inside our report. It doesn't work exactly the same with Activator. By testing it, Activator needs semantic model refresh to ingest the value in the time database, and no matter if you're using specific DAX formulas in your measure such as NOW()... If not (with DQ), it ingests the same value of the last refresh...In this scenario alerting is no longer releviant. Idea: make the ingestion with DirectQuery without any model refresh.
Fabric Activator Alerts Created in Wrong Workspace and Unexpected Save of Alert
The app space and workspace Set Alerts (menu bar) and Add Alerts (ellipses on object) both automatically create the "My Power BI Activator Alerts" in another workspace than the one currently under. Suggest the creation of the Alert only be made on a Save like the Subscriptions. Fix the default selected Workspace saved location to the current workspace and possibly naming the Activator Alert from the default during the initial creation; like Subscriptions. Service Request #: 2502120040007360Enable Activator Rules to Send Emails to Distribution Lists
Currently, Activator rules only sends email notifications to individual internal email addresses. It would be very beneficial to allow Activator rules to send emails directly to Microsoft Exchange Distribution List as well. This will make notification management easy for developers. Instead of updating recipients individually within each Activator rule whenever team members join or leave, administrators could manage membership directly through the Exchange Distribution List. This will reduce effort require for maintenace and help ensure notifications always reach the correct audience. This enhancement will be useful for teams, support groups, and large organizations where notification recipients change frequently.
