User Profile
DataTako
Resolver III
Joined 1 year ago
User Widgets
Contributions
Re: This might cause capacity or licenses issue contact your admin if the problem continue
Hi, The clue is that only the one visual fails, and it's the visual fed by the live connection to the other dataset ("Price Insights"). All your import-mode visuals render fine because they don't leave this model. That one does, and that's where the permission/licensing check bites. The most likely cause is that this is a composite model: a DirectQuery/live connection chained to another Power BI semantic model. Viewing a visual like that requires the user to have Build permission on the source model (Price Insights), not just Read on this report. A plain report a free user can open needs only Read, but the moment a visual has to query a chained dataset, Build on that remote model is required. That's why the rest of the report works and only this visual throws the "connection could not be made / capacity or licenses" error. So first thing to check: does your colleague have Build (not just Read) on the Price Insights semantic model? Grant Build there and that visual should come to life. The reason the message also mentions capacity: if he's on a free license, querying across to another dataset this way needs the content to sit on an F64+ capacity. So confirm both this report's workspace and the Price Insights workspace are on an F64 capacity. If the source model is in a workspace that isn't, a free user will hit exactly this wall even with Build granted. Quick version: give him Build permission on the Price Insights model, and make sure both workspaces are on F64+ capacity. That combination is almost always what fixes this specific "one cross-dataset visual fails for a free user" case. If that sorts it, please mark it as the solution so others hitting the same cross-dataset error find it faster. Paco Helping data analytics leaders distribute their reports114Views0likes1CommentRe: what can i expect from mobile
Hi, Being a report actually helps you here. In Power BI Desktop there's a dedicated Mobile layout view (View > Mobile layout): a phone canvas with a tray of all the page's visuals, and you drag on only the ones you want. So your "only 10% is useful on mobile" instinct is exactly the point, you curate a small prominent subset rather than cramming everything in. Slicers are fair game and stay interactive in the mobile app. Your three radio buttons work too: if they're a single-select slicer they behave like any slicer, and if they're Button visuals wired to bookmarks those render and fire in mobile as well, so your facility/customer/product switch carries over either way. Just note mobile layout is per page, so set it up for each page you want optimised. If this helps, please mark it as the solution. Paco Helping data analytics leaders distribute their reports27Views2likes0CommentsRe: List of users not logged to power BI service with license
Hi, It's a two-source job. Pull who holds a Pro license from Microsoft Graph / the M365 admin center, then pull who's actually used the service from the Power BI Activity Log (Get-PowerBIActivityEvent or the Admin Activity Events API). Diff them: licensed but not in the activity list = your cleanup candidates. The catch is the Activity Log only goes back ~30 days per query, so "long time" is only answerable that far unless you've been archiving it (for longer history, the M365 audit log in Purview retains more). Both need Fabric/Global admin rights, so confirm you have that first, since platform admin alone won't return tenant-wide data. One aside, since this is a cost exercise: if those idle Pro users are mostly just viewers, the bigger lever is that viewers don't need Pro at all on an F64 capacity or when reports are embedded (app-owns-data). A tool like DataTako handles that embedding side, so your next cleanup is smaller because viewers stop consuming seats in the first place. If this gets you the list, please mark it as the solution. Paco Helping data analytics leaders distribute their reports88Views0likes1CommentRe: Detect the new reports in Power BI workspaces
Yes, this is definitely possible, and your proposed flow is basically the right approach. The key issue is the authentication to the Power BI REST API. To retrieve the reports from a specific workspace, you can call: GET https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/reports This returns the reports in that workspace, which you can then compare against the Excel Report Catalog. Microsoft supports this endpoint for workspace report retrieval. The Access to api.powerbi.com was denied message most likely means that the identity used by the automation does not have sufficient Power BI API/workspace access, rather than there being a problem with the flow itself. I would recommend using a Service Principal / Entra App Registration for the automation rather than a personal user account. In the Fabric/Power BI Admin Portal, the tenant setting that allows service principals to call Fabric/Power BI APIs needs to be enabled, preferably for a dedicated security group. The service principal also needs access to each workspace that you want to monitor. Microsoft specifically documents that a service principal needs to be added to the workspace, typically as Member or Admin, before it can access the workspace content through the APIs. So your architecture could be: Scheduled Power Automate / Azure Function → authenticate with Entra ID → GET /groups/{workspaceId}/reports → read Excel catalog → compare report IDs/names → send email for anything missing I would compare using the Report ID where possible rather than only the report name, because names can change or potentially be duplicated. Another option, especially if you have Fabric Administrator access, is to use the Power BI Activity Log instead. The Activity Events API exposes tenant Power BI activities and keeps up to approximately four weeks of history. You could periodically check for report publishing/creation events and send a notification from there. However, for your specific requirement “does a report currently exist in these workspaces that isn't in my catalog?” I actually prefer your scheduled inventory comparison because it also catches reports if an event was missed. So I wouldn't redesign the solution yet. I would first ask your Power BI/Fabric administrator to check: - Whether the identity running the flow has access to the relevant workspaces. - If using a service principal, whether Service principals can call Fabric public APIs / use Power BI APIs is enabled for it. - Whether you're obtaining an Entra access token for the Power BI API before calling api.powerbi.com. Microsoft also has an HTTP with Microsoft Entra ID connector that can call Entra-authenticated endpoints from Power Automate. Once that authentication issue is solved, the rest of the flow you designed should be relatively straightforward.22Views0likes0CommentsRe: I Can't Know Who Has Access To A Report Via APIs
You haven't missed an API, this is a genuine gap. The Apps admin APIs let you enumerate an app's audiences and their members, but they don't expose the audience-to-content mapping, so there's no supported call that tells you "audience A1 can see R1." That's exactly the piece you'd need to reconstruct per-report access, and it isn't surfaced today. The scanner (metadata) API doesn't fill it either. So the airtight per-report answer isn't available purely from APIs right now. A couple of ways people work around it: The audience-to-report mapping itself is static and low-volume, and you can read it from the app's configuration in the UI. If you capture that mapping once (A1 → R1, A2 → R2) and keep it current, you can join it to the audience membership the APIs do return, and that reconstructs who can see R1 vs R2. Not fully automated, but reliable as long as the app structure doesn't churn constantly. If you need it to be fully API-driven and auditable, the cleaner structural fix is one audience per app, or separate apps per access boundary. Then access sits at the app/workspace level, which the APIs report on properly, and you lose the blind spot entirely. Longer term it's worth logging on the Fabric Ideas site, since audience-level content visibility in the admin API is a real reporting gap for exactly the governance use case you're describing.55Views0likes1CommentRe: Power BI Pro Gen 1 Dataflow Refresh Limit: Per Dataflow or Workspace-Wide?
Hi, It's Scenario A: the 8-refreshes-per-day limit is per dataflow, not workspace-wide. So 5 dataflows each refreshing 5 times a day is completely fine, since each one is well under its own 8/day ceiling. Dataflows are feasible for your use case, no need to fall back to materialized views for this reason. If this answers it, please mark it as the solution.58Views0likes0CommentsRe: Moving Semantic Model from east us 2 to east us
Delete-and-republish isn't your only option, and for large models it's the one you want to avoid. The region of your content follows the region of the capacity the workspace is assigned to, so the cleaner route is to move the workspace onto a capacity that lives in East US rather than rebuilding anything.80Views0likes0CommentsRe: Confusion with F64 capacity vs. reservation
Hi, The confusion comes from mixing two separate things: the capacity SKU and the reservation. The free-viewer benefit is tied to the SKU, not to how you pay for it. The SKU (F2, F8, F64, and so on) is the size of the capacity resource you actually provision and assign to a workspace. A reservation is purely a billing construct: a 1-year commitment that discounts your Fabric usage up to a certain number of CUs. It doesn't create a capacity or change its size. So your F2-plus-PAYGO idea doesn't work the way you're hoping. An F2 capacity is an F2 SKU, full stop. Running extra pay-as-you-go usage against it doesn't turn it into an F64, and it won't unlock free-viewer access. The "non-Pro users can read reports" benefit only applies when the capacity you assign is genuinely an F64 SKU or larger. Where reservations do come in is the other direction: you provision a real F64, then pay for it via a reservation, fully PAYGO, or a mix (reserve 32 CU for the discount, let the rest run PAYGO). All of those still give free-viewer rights, because the SKU is F64 regardless of the billing split. What you can't do is assemble an F64's worth of CUs out of a smaller SKU. The reason people go looking for a loophole here is that F64 is a big jump if you don't actually need the compute and just want the free-viewer rights. If that's your situation, the other route is embedding the reports (app-owns-data), where viewers don't need any license and you can run a much smaller SKU. You can build that yourself with the powerbi-client SDK, or use an out-of-the-box embedding solution like DataTako if you'd rather not maintain the token/licensing plumbing. Worth knowing before you commit to F64 purely for the licensing. Short version: deny. It's the provisioned SKU that has to be F64+, reservations only affect price, and if F64 is overkill for your viewer count, embedding is the cheaper path. If this clears it up, please mark it as the solution so others with the same reservation question find it faster. Paco Helping data analytics leaders distribute their reports104Views0likes2CommentsRe: OAuth Token Request Times Out in Power BI (Post Call issue)
Hi, You've diagnosed it well: hardcoding the token works, so it's not the API, it's how Power Query handles the token POST on repeat evaluation. Classic cause is the data privacy firewall. Power BI treats the token endpoint and the API as two separate data sources and re-evaluates how they're allowed to combine on refresh, which is exactly why the first refresh works and the second hangs. Two fixes that usually solve it: set the privacy level on both to the same value (Organizational), and restructure so both calls share one base URL via RelativePath, so Power BI sees a single data source and stops firewalling between them: Web.Contents("https://your-base-host", [RelativePath="oauth2/token", Content=..., Headers=...]) Also add [Timeout=#duration(0,0,1,0)] to the token call so it fails fast instead of hanging for minutes. If that clears it, please mark this as the solution so others hitting the same timeout find it faster.160Views1like0CommentsRe: Iframe continues scrolling after mouse release when interacting with Power BI visuals
Hi, This is a known side effect of the drag interaction crossing the iframe boundary. When you grab a scrollbar inside the report and the cursor leaves the iframe during the drag, the mouseup fires on the parent page instead of inside the iframe, so the visual never receives its "release" event and keeps thinking you're still dragging. That's why it stays stuck until you click again inside the report, which finally hands it the event it was waiting for. The real fix is usually the embedding method rather than the report. If you're pointing a raw <iframe src="app.powerbi.com/..."> at the Service, that path isn't really supported for interactive embedding and these pointer-event quirks are exactly what it produces. Switching to the official powerbi-client JavaScript SDK (powerbi.embed()) is what solves it in practice, because the SDK manages the pointer and message handling between host page and report properly instead of leaving the browser to guess. If you're already on the SDK and still seeing it, then handle the released event on the host side: capture mouseup at the parent document level and forward it so the embedded report knows the drag ended. For what it's worth, if you'd rather not build and maintain the embedding layer yourself, we run an out-of-the-box embedding solution at DataTako.com that handles this pointer/event plumbing (and the viewer licensing side) for you, so it's an option if this turns into more work than it's worth. Either way, happy to help you get it sorted, just let me know how you're currently embedding and I can point you at the specific fix. If this gets it working, please mark it as the solution so others with the same iframe behaviour find it faster. Paco Helping data analytics leaders distribute their reports147Views0likes0Comments
Data Privacy
Microsoft Fabric Community and Privacy
To learn more about how we manage your data, please review the Microsoft Fabric Community Data Privacy guide.