It’s very useful- you can pass filter criteria into the embedded form - so if a person selects a given account then the selected account is can be passed to the Power BI report to report only on that account. You can even be more creative and use it to report on an accounts hierarchy rather than the one specific account

@@PontyclunBosomPals When i create and integrate a dashboard of my power bi account in a solution and in the form, any user can see the dashboard or only those who have a power bi pro licence?

I'm starting to feel this (but I'm more of a noob). I am used to created PowerBI reports & distribution using apps. PowerApps & Dataverse are just another level I don't use and don't understand best practice.

Same thoughts...not sure I understand why this might be a benefit. I currently am linked to an access dbase on a company server through s Gateway. Works great. Why would I change this configuration to data verse? What benefits might I realize?

A lot of benefit in the fact that it's low code. Much more benefit in all of the metadata for records - owner (including team ownership), attachments, and especially detailed table/entity security roles

It’s useful (from a BI perspective) as the database for dynamics is locked down. To report off dynamics you need to export to a SQL database or a data lake. The data verse is a surfaced version of the OLTP database that you can report directly off ( though it will be Odata) or you export out to a data lake or SQL database. Previously Microsoft provided an data exporter using an add in. It wasn’t great and the exports would fail. The data verse to datalake is a lot more reliable and updates quicker. This also has the benefits of a incremental (pseudo real time) export rather than using ADF to pull everything and determine updates. In general unless you are using Dynamics (CE not finance or Talent) then you will not use this.

@@dmor3359 if you are using access you are either using a on premise app or cloud based but taking a hybrid approach and storing data for reporting on premise. In short you are using very old technology (access) that is not designed for even a small enterprise. Access works better for a solo project rather than a company wide solution. If you have small data volumes then you could point power BI directly at the application and using power query for your ETL. If you have decent size volumes then switch to a SQL database to store the exported data. If you have the opportunity to move to the cloud then this brings a plethora of Benefits from cost savings, reduced downtime due to fault tolerance and if you use a azure SQL database (PAAS) you pass on the responsibility for the virtualised architecture to Microsoft allowing you to focus on the application and the insights you can gain from it

Nice 👍🏻😀

Not yet. I love the idea though. 😉

do you know the answer?

Hmm.. this is weird! Dataverse by default is storing its data in ADLS g2 behind the scene. This can be secured by AAD or Azure Synapse link ( I am not sure??). I know all those are preview features though

Good question! I wish someone can provide a solution for this case

It isn't, in fact because of the huge number of table columns (mostly with bloated naming conventions) and also the base64 GUID based record IDs it becomes a poor performing option very quickly. The Base64 GUIDs become a massive bloating factor in any AS Tabular/PBI model with only modest data volumes.

@@christimbers2006 Fully agree. Dataverse connector is slow once you get any volume of data. Had to use TDS endpoint for dataverse which still is a bit slow compare to a "normal" SQL data source