Dataverse Long Term Retention

If we enabled [Block Public Internet Access] in Microsoft Frabric, and then link the dataverse tables to frabric using private link, it will fail even we have set up private endpoints and private link.

We confirmed with PM of the team, this is due to feature not supported, but we hope it will come in a near future as many of developers have to give up on private link.

Thanks!

Archived data need to be surfaced as BI reports, this is a requirement in one of our current project.

This will allow customers to have full control on the kind of interface they want for their users.

When using certain fuzzy searches in the dataverse we can see a certain result match whilst filling in the searchfield (1 match) but when we press enter, this specific result isnt in the "top results page" as the word searched contains characters such as .- (without spaces, 1 long combination).

The result will only be available if we click on the specific entity page.

Idea would be to highlight multiple columns in setup which are seen as the most relevant ones to be displayed on the "top results" page, and therefor improving the general quality of top results

The largest table by far in our system is ProjTransPosting. We've been told it would fall under a project operations LTR scenario if it were to be included in the future. Please consider adding this new scenario.

The customer is facing an issue with deactivating all Dataverse tables that are activated by default in the Azure Synapse Link setup.

During Fabric link export utility by default all data verse table get activate. But as discussed with PG team at this stage we can overcall the 1000 tables limitation but not disable the Dataverse tables.

So need option to de select the Dataverse table with fabric profile

Provide analytics on the Dataverse requests triggered from runs of Power Automate flows. This allows the identification and optimization of flows that are consuming the most requests.

It would be better to make virtualtables from F &O to work on power pages fully functional. currently not all features are inculed or fully working as expected. also documentation related to virtual entities to be updated with latest changes if possible.

Currently, row checksums are created when doing an Excel export and are not present in the table.

However, placing the row checksum in the table, via a connection to OData, would allow for the following actions.

1. Connect the information in the Power Apps table to Excel by acquiring data from Odata.

2. Use PowerQuery in Excel to prepare an Excel file with the same information as the view of the Power Apps application in use.

3. If you want to modify the records in the table, modify the data in the Excel format.

4. Import the corrected Excel file into PowerApps using Excel Import.

This allows data modification through the Excel format when the table within Power Apps is not to be directly modified by an unspecified number of users.

Issue -

When reporting from the phone call exported data the to and from fields contain the same guid as the phone call itself instead of the guids of the chosen lookup records.

Ask -

Yes we ultimately did use activity pointers as a workaround but it is extremely slow and taxing sql operation. Is there any reason the To and From fields on the phone call entity are designed this way? In future we should think about storing phone call recipient information in phone call entity table along/instead of activityparty base table. 

Here just write anything and Click submit