How to Export Underlying Power BI Data to Excel

Illustrative example — underlying export does not mean all rows in the model.

Build permission on the semantic model is required for underlying export. Being able to view the report does not establish that permission. The owner can inspect Manage permissions for the correct model. Request access appropriate to the approved task rather than a broader workspace role as a workaround.

Check report access, model Build access and report/tenant export policies separately. If Underlying data is missing or disabled, give the owner the report and model identifiers so they can inspect the right configuration.

Test with the intended export account. Workspace row-level security restricts Viewers, including those with Build permission, but does not apply to Admin, Member or Contributor roles. An author’s export may therefore differ from a Viewer’s.

Our example assumes an approved account can see both Operations and Support. Its High-priority baseline is three tickets. An account limited to Operations needs a different baseline. Compare against that identity’s authorized records; do not treat every smaller result as truncation or change roles to obtain unauthorized rows.

1. Open the intended report in Power BI Service with the export account. Confirm its semantic model with the owner.
2. Apply the required filters. For the example, select High priority and record the authorized queue scope.
3. Open More options on the relevant visual, choose Export data and select Underlying data if available and suitable.
4. Choose the available Excel option and export. Retain the original file, export time and report context.
5. Open the workbook and compare its actual field names and records with the checks in the next chapter. Use a working copy for sorting or changing displays.

If the option is unavailable, resolve that specific issue with the owner. Besides Build access and permitted export types, model conditions matter: missing unique keys and Show items with no data can prevent underlying export.

A normal menu export is sufficient when it provides the required authorized detail. This is a Service visual workflow; it does not create an export button or convert a Desktop CSV.

For repeated delivery, the PBRS Excel Data Only settings offer summarized or underlying data for the documented Service route. Select the actual page and titled visual, choose the required type, then test the generated workbook under the configured source account. Scheduling cannot correct an unsupported field or an inappropriate data scope.

In this illustrative source, TicketId is the unique text key, Queue supplies the grouping and Priority supplies the filter. The proposed visual groups by Queue and counts TicketId. Confirm which fields a real underlying export returns before relying on this three-column agreement.

Synthetic source
TicketId | Queue      | Priority
T-810    | Operations | High
T-811    | Operations | Normal
T-812    | Support    | High
T-813    | Support    | High
T-814    | Support    | Normal

Illustrative acceptance record
Filter: Priority = High
Authorized queues: Operations and Support
Expected unique TicketIds: T-810, T-812, T-813
Expected detail records: 3
Expected grouped counts: Operations: 1; Support: 2

Check the actual file:
required field names present
TicketId text values preserved
no missing or duplicate required keys
all accepted rows within the agreed scope
no omission warning
export identity and reporting context retained

The useful detailed output contains T-810, T-812 and T-813, with enough fields to establish their queue and priority. Neither Normal-priority ticket belongs in that extract. The records and counts were checked locally; no live Power BI export was performed.

Compare keys as well as counts. A file with T-810, T-812 and T-812 has three rows but duplicates one ticket and omits T-813. The local fixture check detected this deliberately constructed mismatch. It verifies the example’s logic, not an actual export.

If a column is absent, review field selection and model behavior with the owner. Do not substitute another field or assume the source was blank. Underlying-export guidance excludes datetime and variation columns, numeric columns when aggregated, and visual calculation results. Base the agreement on supported, inspected fields.

Check for omission warnings too. Standard visual XLSX output has method-specific limits and may fall below the headline ceiling. If the authorized detail does not fit, consider a designed detailed report or approved extract with its own controls. Keep the same scope and level of detail when comparing results.

Accept the example’s output when the required fields, three unique High-priority IDs and queue counts agree with the authorized baseline. Keep the original file and acceptance record. Use a summary when recipients need counts; use detail for a defined record-inspection task.

If the required detail is unavailable, give the owner the report, visual, account, export mode and missing fields. Resolve that issue before scheduling. When the checked visual export becomes recurring work, PBRS report automation can repeat the supported process.

Return to Power BI Questions for the related export workflows.

Considering PBRS for recurring underlying-data exports? Share the guide with your colleagues to review deployment, licensing, security and your reporting requirements.

Download the PBRS Internal Evaluation Guide