Microsoft Forms has no general-purpose Power BI connector that turns every form into a governed, real-time report. The two sensible patterns are to report from the form's Excel response workbook, or use Power Automate to copy each submitted response into a controlled destination such as a SharePoint list or Dataverse table.
Choose based on ownership, data volume, latency, licensing and what happens when the form changes.
Route 1: report from the response workbook
In Forms, open the form, select Responses, then Open results in Excel. Microsoft documents that the workbook location depends on how the form was created. Personal forms normally place the workbook in the owner's OneDrive. Group forms place it in the group's SharePoint site.
Connect Power BI to the workbook through the supported OneDrive or SharePoint route. Avoid copying a browser sharing URL into the generic Web connector and assuming refresh will remain stable.
This route is appropriate when:
- the form and workbook have a durable owner
- the response schema changes rarely
- workbook refresh behaviour meets the reporting need
- respondents' data can be processed under the workbook's permissions
Test a new response from submission to report refresh. Do not claim a fixed refresh interval unless the configured Power BI licence, capacity and refresh history prove it.
Route 2: copy each response with Power Automate
Create an automated cloud flow with the Microsoft Forms trigger When a new response is submitted. Then add Get response details using the response ID supplied by the trigger.
Write the required fields to a destination with an explicit schema. A SharePoint list can suit a Microsoft 365 team process. Dataverse can suit applications needing richer relationships, security and lifecycle controls, but it changes licensing and administration.
Important boundaries:
- A group form might not appear in the picker. Microsoft documents using the form ID from its URL as a custom value.
- The Forms connector exposes submitted responses. It is not a general API for redesigning forms or extracting every historical state.
- File-upload questions need separate handling and permissions.
- Power Automate runs can fail. Add monitoring and a reconciliation process rather than assuming every submission arrived.
- Connector and destination licences must be checked for the actual tenant.
Model the data before building visuals
Keep a response identifier, submission timestamp and source form identifier. Convert timestamps deliberately, because the connector's submission time is in UTC. Use stable question keys where possible. Renaming a question can break mappings that rely on generated dynamic-content labels.
Do not put sensitive free text straight onto a broadly shared report. Decide who may see raw responses, whether aggregation is sufficient, and how deletion or correction requests will flow through every copy.
What about Graph API?
Do not promise a Microsoft Graph Forms API for this scenario unless Microsoft publishes and supports the exact endpoint you intend to use. For ordinary business automation, the documented Forms connector and response workbook are the safer starting points.
Validation checklist
- Submit a test response with every question type used.
- Confirm the response reaches the destination once.
- Check types, blanks, time zone and choice values.
- Force a failed destination write and confirm it is visible.
- Refresh the semantic model and compare row counts.
- Test report access as a normal viewer.
- Record ownership and recovery steps.
Sources
- Check and share your form results
- How to do more with Forms in Power Automate
- Microsoft Forms connector reference
- Refresh data in Power BI
Make the reporting chain observable
The Microsoft 365 Report Builders Space is for people working through data ownership, refresh and report reliability. Use anonymised examples only.