AI-driven analytics over Power BI Semantic Models – architecture discussion
Hi Fabric community, I would like to share an architecture experience and get feedback from the community. We have implemented an AI-assisted analytics layer over Power BI Semantic Models. The solution allows business users to ask questions in natural language and perform analysis directly against Power BI models. The architecture includes: Semantic model metadata understanding Query planning DAX generation and execution Query validation and governance controls Our implementation uses a dedicated intelligence layer around Power BI rather than an MCP-based approach. With the recent interest in Power BI MCP and Fabric MCP, I would like to discuss: How do you see custom AI analytics layers compared with MCP-based integrations? What are the recommended architectural patterns for enterprise AI agents working with Power BI Semantic Models? I would be happy to share more details about our implementation experience.Microsoft Fabric Data Agent Governance: From POC to Production
In Part 1, we discussed — Who can access what? Click Here to read Part 1 We looked at identity, source permissions, RLS, CLS, OLS, query-path security, and why AI instructions should never become the authorization layer. But a Data Agent can be perfectly secure and still be poorly governed. Once we move from a POC into production, a different set of questions appears: Who can modify the agent? Which identity is used when the agent is called from another application? How do we test an instruction change before releasing it? What changes when Code Interpreter is enabled? Where does conversation history live? What happens when the Data Agent leaves Fabric? That is where the conversation moves from security into governance. Security and Governance Are Not the Same Thing SECURITY Who can access the agent and the data? What rows, columns, or objects can they see? GOVERNANCE Who can change the agent? How are changes tested and quality measured? Which runtime is used? Where is conversation data stored? How is the agent consumed outside Fabric? Security defines the boundary. Governance controls how the system is operated inside that boundary. Both are required for production. Fig. Security Vs Governance Code Interpreter Introduces Another Execution Surface The normal Data Agent source-query path (SQL, DAX, KQL) is read-oriented, so a prompt like "Delete all customers with zero revenue" doesn't turn the agent into a database administrator. But there is a nuance: Fabric Data Agent can optionally use Code Interpreter, which generates and executes Python in a Microsoft-managed sandbox for statistics, transformations, and charts. Underlying source │ Governed retrieval ▼ Fabric Data Agent │ ▼ Sandboxed Python execution │ ▼ Calculated / transformed / visualized result The source-query path remains governed and read-oriented, while Code Interpreter introduces an additional analytical execution environment. Rather than treating the word "sandbox" as sufficient evidence, we tested the execution path directly. What We Observed in Our POC Governed data was retrieved before Python executed. For "Total Sales by Region", the Run Steps showed the semantic model queried with DAX first. The authorized result was saved as a local JSON file under /mnt/data and then read by pandas. Code Interpreter was not independently querying the model. The sandbox could create local artifacts. Generated Python wrote files such as CSV and TXT into /mnt/data, and the Run Steps exposed the code used. Artifacts persisted across chats for the same user. A file created in one chat was still visible in a new chat. We do not infer a retention period from this; the lifetime remains unknown. A second user did not see the first user's artifact. User B enumerated files and found only their own test file. This is POC evidence consistent with user-level isolation in our environment, not a universal guarantee. Runtime details were visible, but sensitive introspection was constrained. Python version, OS, and package versions were exposed, but a request for environment-variable names was refused before execution. Outbound internet was treated as disabled. A requested HTTPS call was not issued and the environment reported internet access as disabled. Since no connection was attempted, this is not packet-level verification of a network block. A controlled Python error exposed nothing sensitive. Referencing a nonexistent column returned only a KeyError, with no credentials, connection strings, or unrelated file contents. Fig. Run Step showing the DAX query and generated Python reading the result file Fig. Same-user artifact persistence across chats Fig. New chat shows file exists. Fig. In our test, User B could enumerate their own isolation artifact but not User A’s artifact. Fig. Area of observations These are POC observations, not universal guarantees. For production, treat Code Interpreter as its own governed execution surface and ask: What data reaches Python? What code is generated? What artifacts persist, and for how long? Are users isolated? What can the environment reach? What appears in errors? Read-only source access does not mean there is only one execution surface. The Calling Identity Becomes Critical Outside Fabric Inside Fabric, identity is easy to reason about. A published Data Agent can also be called by custom applications, MCP clients, and automation, each with a different identity path. One architecture question should always be documented: Whose identity ultimately reaches Fabric? Service principals suit automation, CI/CD, and background processing, but they carry their own permissions. If User A, B, and C all reach the agent through one shared service principal, the platform evaluates that single identity, not each user's entitlements. For interactive apps where per-user entitlements matter, a delegated (on-behalf-of) identity is usually easier to reason about. Neither is universally better: The identity model must be intentional. Fig. Calling Identity Governance Starts Before the Agent Is Published Who can change the Data Agent is almost as important as who can use it. Creators work in a draft version (schema, instructions, examples, sources); consumers use the published version. A normal consumer shouldn't need edit rights to a definition like "Revenue means Net Revenue excluding intercompany" just to ask "What was revenue last month?" Separate four responsibilities: consume, inspect, edit, publish. Treat Data Agent Configuration Like Code Once instructions define business behavior, changing them is a production change. "Change instruction, save, hope nothing broke" is not a governance process. A stronger lifecycle: Development → Source control → Peer review → Test workspace → Regression validation → Production → Publish You should be able to answer who changed an instruction, what changed, which version was tested, and which version is running in production. Fig. Lifecycle Standard vs. Preview Runtime Is a Governance Decision A POC may use Preview capabilities for newer functionality; production may prefer the stable path. But even a standard runtime doesn't mean the underlying AI stack stays frozen. "We tested it once" is not a strategy, so regression testing has to become part of normal operation. Security Is Not the Same as Accuracy A response can be perfectly secure and still wrong. For "What did we spend on marketing last quarter?", an authorized user still depends on the agent interpreting "spend", "last quarter", which accounts count as marketing, and which source is authoritative. Production governance needs two questions: Was this user allowed to see the answer? and Was the answer actually correct? Native Evaluation Should Be Part of the Release Process "We asked five questions and the answers looked okay" is not a release gate. Maintain expected-answer test cases and run them on every change. A good set includes core KPIs, time-intelligence questions, synonym variations, ambiguous prompts, cross-source questions, restricted-data questions, expected failures, and known edge cases. When something fails, Run Steps help locate the divergence: wrong source, wrong query, wrong business interpretation, or a misleading explanation. Instead of "the AI got it wrong", ask where did the execution path diverge from what we expected? Fig. Security vs. Quality Evaluation Conversation History, Residency, and Networking Conversation history is part of the data estate. A prompt like "Why is revenue falling for Customer ABC while we negotiate their confidential renewal?" may be more sensitive than the result. Decide what users may enter, how long context persists, and who can investigate interactions. Data residency needs an explicit decision. Document more than where the capacity lives: where AI processing occurs, where conversation history and telemetry are stored, and where downstream applications process the response. Networking must be evaluated per source. Private Link (how do we privately reach a resource?) and Outbound Access Protection (which destinations may this workspace call?) solve different problems, and not every source follows the same path. As in Part 1: validate the actual path, not just the existence of a security feature. Fig. Conversation History, Data Residency, Networking What Happens When the Data Agent Leaves Fabric? A Data Agent can be used through Microsoft Foundry, Copilot Studio, Microsoft 365 Copilot, MCP clients, and custom applications. Once the response leaves Fabric, the receiving service brings its own identity model, retention policy, logging, compliance boundary, and geography. "Secure inside Fabric" does not mean "secure everywhere downstream." The same applies to identity. If the application calls Fabric as the user, the user's permissions apply. If it calls as a shared or maker identity, answers reflect that identity's permissions instead. The second pattern may be intentional, but it must be documented as a security and governance decision. Fig. When the Data Agent Leaves Fabric A Production Governance Model IDENTITY → AUTHORIZATION → DATA SECURITY → QUERY-PATH SECURITY → AI SCOPE → SEMANTIC GOVERNANCE → EXECUTION GOVERNANCE → QUALITY GOVERNANCE → LIFECYCLE GOVERNANCE → FABRIC DATA AGENT Part 1 covered the upper security layers. Part 2 adds the controls needed to operate the agent as a production analytical product. Fig. Data Agent Ready for Production Before Production, I Would Review These Areas Identity: confirm which identity reaches Fabric; document user, delegated, and service-principal paths separately. Data security and scope: validate RLS/CLS/OLS with real restricted identities on every query path; expose only the sources and fields required. Execution: document the runtime; review Code Interpreter separately (data passed to Python, artifact persistence, isolation, network limits). Quality: maintain expected-answer tests; regression-test critical questions. Lifecycle: separate consumers from creators; use draft and published versions; promote through Dev, Test, and Production; version instructions. Privacy, residency, network: define prompt rules, document AI processing and telemetry locations, review Private Link per source. External consumption: re-run the review for every channel and confirm the effective identity for each. Governance Still Does Not Tell Us What Happened The agent may now be secure and well governed, but production still raises questions: Who asked what? What did the agent answer? Which source did it choose? Where did execution fail? Can compliance investigate an interaction? These map to three disciplines: Audit (who asked what, and what was answered), Trace (how a request executed), and Observe (whether the agent is healthy in production). Next: Part 3 — Auditing, Tracing and Observing Microsoft Fabric Data Agents in Production Part 3 will combine Microsoft Purview, DSPM for AI, Microsoft Foundry, Application Insights, Fabric diagnostics, capacity telemetry, and MCP/application telemetry to answer not just what the Data Agent is allowed to do, but what it actually did. That is where security and governance turn into operational accountability. Related Reading Part 1 — Microsoft Fabric Data Agent Security: What Actually Protects Your Data? Building a Better Microsoft Fabric Data Agent: Instructions, Visual Policy, and Cost-Aware Design Building and Enriching a Microsoft Fabric Data Agent on a Power BI Semantic Model
Fabric Data Agent Access issue
I have created a fabric data agent using semantic model of a published report, It is working fine but I'm not able to share it with others I published the agent in M365 copilot and share with my teams of 100 people only 4 or 5 people can go to M365 copilot and search the agent and added the agent to their agent tab others are not even seeing the agent but if I share the agent link from M365 copilot then they see the agent but agent is not answering the questions but it's perfectly answering for me and other 4 to 5 people who see the agent when I surfed it said it said there are 2 level of access to get answer from the agent 1. agent level access 2. underlying data level access I have workspace contributor access for workspace, read, write, reshare permission for the agent. most of them share the same access but there are not able to see the only difference I found is I'm having premium per user license and most of other have pro license so I doubted it but internet says license is not an issue can anyone pls help me with this issue
Power BI Field Parameters with Paginated Reports – Looking for Guidance
Power BI Field Parameters with Paginated Reports – Looking for Guidance Hi everyone, I am trying to understand the best approach for using Power BI Field Parameters with Paginated Reports. I understand that Power BI Field Parameters allow users to dynamically switch between fields or measures in a Power BI report. My question is whether similar functionality can be achieved when working with Paginated Reports. For example, I am looking for something like: Power BI Report → Field Parameter → Paginated Report → Dynamically change the field/column displayed or used by the Paginated Report Specifically: Can a Power BI Field Parameter be passed to a Paginated Report? Can a Paginated Report consume a Power BI Field Parameter directly? Can a Field Parameter be used to dynamically determine which column/field is used in a Paginated Report query? If Power BI Field Parameters are not supported for this scenario, is there an equivalent out-of-the-box feature in Power BI Report Builder / Paginated Reports? Can this be achieved using standard Paginated Report Parameters, expressions, or dynamic query logic? Is the Paginated Report visual in Power BI the recommended way to achieve this type of interaction? For example, the desired experience would be: User selects: Customer Name OR Product Name OR Supplier Name and the Paginated Report dynamically uses the selected field/column. I understand that Power BI Field Parameters and Paginated Report Parameters are different concepts, so I am specifically trying to understand whether there is a supported way to achieve the same dynamic field-selection experience in Paginated Reports. If anyone has implemented this scenario, I would appreciate guidance on the supported approach and any limitations. Thanks!
Why I Build Muscle & The AMAZING Benefits of Best Anabolic Steroids
This is a mean way to be distinguished for dealing in an ongoing basis with this. The key gist is to simply get Best Anabolic Steroids. Indeed, that has gotten really ugly. They received a modest rebate. This principle wasn't available. I was very surprised, but it works well. It's just around the bend and I reckon you'll find this interesting reading. https://bit.ly/3AEojPe
Building AI-Powered Features Around Power BI Embedded Analytics
Hi everyone, I am exploring ways developers are extending Power BI solutions with AI-powered capabilities. Many applications today need more than dashboards — they need intelligent features that can help users understand data, generate insights, and automate decision-making processes. I am interested in understanding how developers are approaching this architecture. Some questions: - How are you integrating AI capabilities with Power BI Embedded applications? - Are you using Power BI APIs together with external AI services for generating insights? - What are the recommended approaches for allowing AI systems to query and understand Power BI datasets securely? - How do you handle permissions and data access when adding AI features on top of business intelligence platforms? Would love to hear about real-world implementations and best practices from developers working with Power BI integrations. Thanks!How are teams automating Power BI development workflows using AI agents?
I am exploring how AI agents can help automate repetitive tasks in Power BI development and data workflows. Some possible use cases: Automatically generating reports from business requirements Triggering data preparation workflows through APIs Validating datasets before publishing dashboards Detecting anomalies and suggesting improvements Automating documentation for datasets and reports I am interested in learning how developers are currently combining Microsoft Fabric, Power BI APIs, notebooks, and AI agents. What architecture patterns or best practices are you using for AI-driven BI automation?Microsoft Fabric Data Agent Security: What Actually Protects Your Data?
Most Microsoft Fabric Data Agent demos begin the same way: connect a semantic model, Lakehouse, or Warehouse, add some instructions, ask a natural-language question, and get an answer. That's the exciting part. But the moment we move from a demo to a real enterprise implementation, the questions change: Whose identity is actually querying the data? Does sharing the Data Agent also share the underlying data? Can the agent bypass RLS or CLS? Does Object-Level Security still protect metadata? What happens if the same data is reachable through multiple query paths? These are the questions we set out to answer during our Fabric Data Agent POC. The most important principle that came out of it was surprisingly simple: The Fabric Data Agent should not be your security layer. Your data platform should be. That one principle makes the rest of the architecture much easier to reason about. A Data Agent Does Not Get Unlimited Access to Fabric When someone uses a Fabric Data Agent directly in Fabric, the interaction normally runs in the context of the authenticated Microsoft Entra ID user. Fabric manages the underlying Azure OpenAI service, so users don't need to supply an OpenAI API key, and the Data Agent doesn't suddenly receive unrestricted access to every table in the workspace. When the agent needs data, it generates the appropriate SQL, DAX, or KQL and queries the underlying source using the permissions available to the calling identity. Fig. Security Path The important part is the middle: the agent generates the query, but the data platform decides whether that query can return the requested data. That is exactly where enterprise security should live. Sharing a Data Agent Does Not Mean Sharing the Data There are effectively two authorization checks: Can the user access the Data Agent itself? Can the user access the underlying data source? Fig. Two Authorization Checks Fabric doesn't elevate a user's access just because a Data Agent has been shared with them. Users still need the applicable permissions on the underlying source. Queries that touch data they can't access can fail authorization or return no data, depending on the source and its security model. This separation is critical for enterprise deployments: you can distribute one common analytical assistant while still preserving different data entitlements for Finance, Sales, Operations, or regional teams. Semantic Models Have an Interesting Permission Model Power BI semantic models are especially interesting here. Microsoft documents that a consumer can query a semantic model through a Data Agent with Read permission. They don't need: Workspace Member Workspace Contributor Build permission Write permission simply to ask questions through the Data Agent. (Build or Write permissions remain relevant when someone needs to modify the model or use capabilities that change its AI configuration, such as Prep for AI.) From a least-privilege perspective, this is a very useful improvement. Instead of granting broad workspace or semantic-model permissions just because somebody needs conversational analytics, you can grant only the narrower access required for consumption. What Happens to RLS and CLS? This is probably the security question that comes up most often around conversational analytics: "If the AI generates the query, can it somehow bypass RLS?" For supported Data Agent interactions, Microsoft explicitly documents that existing user permissions continue to apply, including Row-Level Security (RLS) and Column-Level Security (CLS). Fig. RLS — One Agent Three Users All three users can use the same published Data Agent, yet the semantic model can return different populations because the security context belongs to the user. The agent doesn't need instructions like: If User = John, only show Europe. In fact, that would be the wrong way to implement security. The model should enforce the rule. The Data Agent should operate inside it. What About OLS? We tested Object-Level Security (OLS) rather than assuming how the Data Agent would behave. In our model, we applied OLS to Customer[Company Name] in the Power BI semantic model and tested the Data Agent using the restricted identity. We then asked: "Show Total Sales by Company Name." Fig. Data Agent does not expose the OLS-protected Company Name field. The Data Agent responded that the model does not contain a Company Name field and suggested Customer Name instead. Fig. Run Steps show the semantic model was analyzed, but the protected field was unavailable to the agent. That was the key result. Company Name still physically exists in the semantic model, but for the OLS-restricted user, the Data Agent behaved as though the field didn't exist. In our tested path, OLS protected not only the data but also the object's metadata. Our test confirmed OLS enforcement for the tested Fabric Data Agent → Power BI semantic model path, including metadata hiding. There's an important qualification: this remains query-path specific. If the same underlying data is also exposed through a Lakehouse, Warehouse, SQL endpoint, or another source, that route needs its own security controls. Fig. OLS security Security Is Specific to the Query Path This is one of the broader lessons from our POC. Imagine the same business data can be reached through: Power BI Semantic Model │ └── RLS / CLS / OLS Lakehouse │ └── OneLake / item security Warehouse │ └── SQL / OneLake permissions Securing one route doesn't automatically prove that all the others are equally secure. The semantic model could correctly restrict a user's data through RLS or OLS while the same user has broader access to the underlying Lakehouse. If both are available to the Data Agent, the overall architecture may still be over-permissioned. So the enterprise question isn't simply "Does my semantic model have RLS?" It's: Is every query path available to this Data Agent secured for this identity? Fig. Security Is Specific to the Query Path AI Instructions Are Not Security Policies Consider an instruction like: Never display employee salary information. That may be useful behavioral guidance, but it is not an authorization boundary. A user could phrase the question differently. The orchestration could change. A future runtime could interpret an instruction differently. The instruction could be accidentally edited or removed. The secure implementation puts the control in the data platform (RLS/CLS/OLS and source permissions), with instructions layered on top for behavior. Fig. AI Instructions Are Not Security Policies The distinction is simple: Instructions determine how the agent should behave. Permissions determine what the agent is allowed to see. Never reverse those responsibilities. Reduce the Agent's Data Surface Security isn't only about identity — it's also about how much data you expose to the agent in the first place. When configuring a Data Agent, creators select relevant sources, tables, and schema context. For an enterprise Finance Data Agent, exposing: Dim Date Dim Account Dim Cost Center Fact Actuals Fact Forecast is usually better than exposing hundreds of unrelated HR, customer, and operational tables. It helps in two ways: it reduces unnecessary exposure, and it improves query generation because the agent has fewer irrelevant paths to reason through. But schema selection still isn't authorization. Fig. Three Boundaries Data Agent Querying Is Read-Oriented — With an Important Nuance The normal Data Agent source-query path is designed for analytical retrieval. Its SQL, DAX, and KQL tools retrieve and analyze data rather than modify the underlying source. So a prompt like: Delete all customers with zero revenue. doesn't turn the Data Agent into a transactional database administrator. That lowers risk significantly compared with giving an autonomous agent unrestricted write-capable database tools. But there's a nuance. Code Interpreter Changes the Execution Surface Fabric Data Agent can optionally use Code Interpreter (currently in Preview), which generates and executes Python in a Microsoft-managed sandbox for tasks such as statistics, advanced calculations, data transformation, visualization, and analytical processing. That does not make the underlying source write-enabled. A better mental model: Underlying Source │ │ Governed read ▼ Fabric Data Agent │ ▼ Sandboxed Python │ ▼ Calculated / visualized result Fig. Code Interpreter Surface Source querying remains governed and read-oriented, while Code Interpreter adds an additional analytical execution environment. That extra execution surface should be reviewed deliberately, especially when considering Preview capabilities for sensitive production workloads. Discussed in Part 2 with detailed analysis. Check Out. What We Took Away From the Security POC The cleanest security model for us became: IDENTITY Microsoft Entra ID ↓ AUTHORIZATION Fabric item + source permissions ↓ DATA SECURITY RLS / CLS / OLS / OneLake / SQL ↓ QUERY-PATH SECURITY Validate each available source ↓ AI SCOPE Selected schema ↓ FABRIC DATA AGENT The Data Agent sits on top of the security architecture. It should not replace it. That's the difference between building an impressive AI demo and building an enterprise analytical agent. Fig. Security Architecture Security Is Only the First Layer Once the basic security model is in place, a new set of questions appears: Who can modify the agent? Which runtime should production use? How do we test changes? What happens with Code Interpreter? How should service principals be handled? Where is conversation history stored? What happens when the agent is used from Copilot Studio, Foundry, MCP, or a custom application? Those are no longer just security questions — they're governance questions. Next: Part 2 — Governance, From POC to Production Part 2 focuses on how a production Data Agent should be changed, tested, released, consumed, and governed — including identity models, lifecycle management, evaluation, privacy, data residency, networking, and external consumption: Microsoft Fabric Data Agent Governance: From POC to Production. The central idea remains the same: Do not make the AI responsible for protecting the data. Make the data platform responsible for protecting the data, and make the AI operate inside those boundaries. Click Here to go to Part 2 Related Reading Building a Better Microsoft Fabric Data Agent: Instructions, Visual Policy, and Cost-Aware Design Building and Enriching a Microsoft Fabric Data Agent on a Power BI Semantic ModelPower BI Report Usage Metrics – Workspace-Level and Organization-Level Usage
Power BI Report Usage Metrics – Workspace-Level and Organization-Level Usage Hi everyone, I am working on a Power BI governance requirement around report usage metrics, and I am trying to understand the recommended approach at both the workspace level and organization/tenant level. I have some initial understanding of the available options, but I would like to get confirmation from the community and understand if there are better/native approaches. Workspace-Level Report Usage If I have multiple reports within a single workspace, I would like to see the usage metrics for ALL reports in that workspace in one place. For example: Workspace A Report 1 → Views / Unique Viewers / Last Viewed Report 2 → Views / Unique Viewers / Last Viewed Report 3 → Views / Unique Viewers / Last Viewed Instead of opening Usage Metrics separately for each report. My understanding is that the Usage Metrics semantic model can potentially be used to create a custom usage report for the workspace. However, I would like to confirm: How exactly can we get usage metrics for all reports within a single workspace? Is there a supported way to remove/modify the report-level filtering so that the Usage Metrics semantic model covers all reports in that workspace? Is this the recommended approach for workspace-level usage reporting? Are there any limitations with this approach? Organization-Level Report Usage The next requirement is to go beyond a single workspace. I would like to build a centralized view such as: Organization → Workspace → Report → Views → Unique Viewers → Last Viewed → Other Usage Metrics For example: Organization Workspace A Report 1 Report 2 Report 3 Workspace B Report 4 Report 5 Workspace C Report 6 Report 7 All of this should ideally be available in one centralized Power BI governance report. For this requirement, I know there are some possible approaches, such as: Using Power BI/Fabric Admin Portal capabilities with the required admin access Using Power BI Admin APIs Using Power BI Activity Log APIs Building a custom data collection process and storing the information in a Fabric Lakehouse/Warehouse/SQL database But my questions are: Are these the only practical/supported ways to achieve organization-wide report usage? Is there any native Power BI/Fabric feature that already provides tenant-level usage metrics across all workspaces? Can the standard Usage Metrics semantic model be consolidated across multiple workspaces? Is there another Microsoft-supported API or Fabric capability that is better suited for this requirement? What permissions/admin roles are actually required for the different approaches? Workspace-Level vs Organization-Level I am particularly interested in understanding whether the recommended architecture is different for these two scenarios: Scenario A: Single Workspace → All Reports → Usage Metrics Scenario B: Entire Organization → All Workspaces → All Reports → Usage Metrics Would we use the Usage Metrics semantic model for Scenario A and Admin APIs/Activity Logs or another centralized source for Scenario B? Or is there a common approach that can handle both? Historical Usage Another concern is data retention. My understanding is that the current Usage Metrics experience has a limited historical window, with the new Usage Metrics experience retaining 30 days of data. If we need to retain usage information for: 6 months 1 year Multiple years what is the recommended approach? Would this be the appropriate architecture? Power BI / Fabric Usage Data → API / Activity Log / Other Source → Fabric Lakehouse / Warehouse → Historical Usage Table → Centralized Governance Dashboard Or is there a Microsoft-native approach that can retain this historical information without building our own storage layer? Final Architecture Question Ultimately, I am trying to determine the recommended approach for: Organization ↓ Workspace ↓ Report ↓ Usage Metrics ↓ Historical Usage I would appreciate guidance on: How to achieve workspace-level usage for all reports How to achieve organization-wide usage across all workspaces Whether Admin Portal/API/Activity Log approaches are the only options Whether there is a native Fabric/Power BI capability I may be missing How to handle the 30-day Usage Metrics retention limitation Recommended architecture for long-term Power BI governance and usage tracking Thanks in advance to anyone who can share their experience or recommended approach.
