Power BI Email Subscription Limits and Delivery Options

Use the limits below to identify what changes for your reporting job. PBRS adds another delivery route; it does not remove every source, export or mail restriction.

See the subscription guide for current count, frequency, attachment and Run now rules. The troubleshooting guide covers hidden-page counting and external delivery suppression.

The main guide says “no more than 20 pages”; troubleshooting uses “fewer than 20.” Test the actual report in its subscription editor when it approaches that boundary, including hidden pages.

For group aliases, distribution groups, dynamic distribution groups and mail-enabled security groups are eligible; Microsoft 365 and ordinary security groups are not. PPU does not support group aliases. Use the distribution-list guide for the full setup.

An editable workbook, recipient-specific files or a SharePoint delivery should be designed around that result. Saved filters and dynamic recipient mapping belong to their specialist workflows, rather than a collection of copied preview subscriptions.

For this illustrative setup, the operations manager needs an internal weekly preview and a link to Operations Summary. No attachment or personalised output is required.

1. Confirm access. Check the report type, recipient access and owner’s subscription rights. Ask the administrator to confirm tenant subscriptions are enabled.
2. Create the subscription. Open the report, select Subscribe and create a subscription with a meaningful job name. Add the approved test recipient.
3. Select the view and timing. Choose the report page, weekly recurrence, weekday and time zone. Include the preview and report link.
4. Review the dates. Check start and end dates and name who will extend or change the subscription.
5. Test the email. Save and use Run now. This sends a test; it does not refresh the semantic model, the report’s data source.
6. Try the recipient experience. Inspect the preview and reporting period, then open the link using the intended recipient’s account.
7. Keep the job record. Record the name, owner, output, cadence and test result. Recheck after a report-page or account change.

Move to a file job when the request changes

If the customer needs a full PDF, reassess workspace eligibility, page count, size and external-recipient rules. If finance needs XLSX rows, choose a paginated or data-export route.

For a recurring PBRS file job, select the report and output, add an Email destination and approved recipient, then set its timing. Keep automatic delivery disabled while testing. Execute the schedule to a test mailbox and open the received file before enabling recurrence.

The PBRS Email destination guide documents the destination fields and attachment delivery. Source access and rendering prerequisites remain; changing schedulers does not make every file or recipient available automatically.

If the manager needs a workbook or full document rather than a preview and link, give the application a reporting job that describes that result. The job should say which report to produce, which period it covers and who may receive it.

Map the request to a PBRS schedule

For example, an authorised manager’s “Send weekly operations report” action can call a tested PBRS schedule. Configure the source, required output and approved destination first. The schedule create-and-update guide covers the source-specific definitions; the destination guide explains output and recipient settings.

Illustrative application record — not a PBRS request schema
action: Send weekly operations report
period: approved reporting week
approvedScheduleId: ID from your PBRS installation
output: agreed PDF or workbook
audience: approved operations managers
acceptance: correct period, required content, received output

Keep that record beside the application request. Authorise the manager on your backend, then execute the selected job with POST /api/Schedule/ExecuteScheduleAsync. Store its ExecutionId and use GetExecutionStatus to follow the run. Inspect the parsed execution result and the actual delivered file before reporting success. Follow the PBRS execution guide for the complete request.

When formats or audiences change, review the saved job before the next run. Use the correct source-specific update contract, preserving the settings and destination IDs you still need. Keep simultaneous users’ configurations separate, and reconcile a timeout before retrying.

Compare the native and custom routes

A native subscription can remain the simplest choice for a permitted preview or attachment. Run now is a subscription test, not a high-frequency reporting service. If you build directly on Microsoft’s standard-report Export to File API, check its supported formats and hosting requirements; it is not a general XLSX data-export endpoint. Microsoft’s export documentation explains that route.

PBRS is relevant when the application needs the configured reporting and delivery job, rather than its own export-and-email implementation. It still needs suitable report access and a supported output configuration. Test the actual result the manager will use.

Keep the native subscription for the manager’s weekly preview and link when the timing and access rules fit. An eligible attachment can also be sufficient for a retained document.

Choose PBRS when the request becomes a recurring file-generation and delivery job. Maintain the report output, destination, timing and operational handling together, rather than repeating manual exports or collecting separate send steps.

Use one representative report to make the decision. Verify the received file and recipient experience before enabling wider delivery. Test again when the format or audience changes.

See the PBRS report distribution workflow. Explore Power BI Report Automation.

Technical sources reviewed: 8 October 2026.

If subscription limits are holding up your report delivery, share the guide with your colleagues to review deployment, licensing, security and your reporting requirements.

Download the PBRS Internal Evaluation Guide