Schedule a Demo
Schedule a Demo
Book a Demo
POWER BI QUESTIONS

Power BI Dynamic Subscriptions and Data Driven Report Delivery

Yes. Power BI dynamic subscriptions can send each recipient a different filtered view of the same report, using recipient data to supply the email address and filter value. The native feature needs a Premium or Fabric capacity workspace and supports one value per mapped filter.

For example, North and South managers can receive their own regional sales reports every Monday. PBRS data-driven schedules take over the repeated work of reading approved records, applying filters and choosing formats and destinations when that delivery needs more than native email.

THE DIRECT ANSWER Map Each Recipient to the Intended Report View
  
THE DIRECT ANSWER

Map Each Recipient to the Intended Report View

North and South managers mapped to their own regional sales reports.

Illustrative mapping — confirm recipient, region and resulting file.

Imagine two regional managers waiting for Monday’s sales figures. The North manager needs North sales; the South manager needs South sales. A dynamic subscription reads a recipient list and applies the right Region value for each person, instead of sending both people one saved view.

For this example, the recipient data contains north.manager@example.com with North, and south.manager@example.com with South. These are illustrative addresses. Use approved real mailboxes for a delivery test, and check that each received report excludes the other region.

Native Power BI reads these values from a recipient semantic model—the organized data behind the recipient list. PBRS can read a SQL or JSON data driver, meaning records that control each report run. Either route replaces a growing set of manually maintained subscriptions with a maintained mapping.

Microsoft’s dynamic subscription guide explains the native mapping. This page covers standard Power BI reports; paginated reports have a separate parameter-based workflow.

Keep the two data sources clear

The recipient model holds addresses and filter values. The report model holds the sales data. Their column names can differ: you explicitly map the report’s Region field to the chosen recipient-data field.

Approve who can receive each view

A Region filter controls the intended output; it does not prove a manager is entitled to that data. Approve the audience and data scope separately. Receiving an email also does not grant permission to open the report interactively.

Use one record for one intended result

Define what each row should produce before configuring delivery. A blank address, unapproved mailbox or unknown Region value needs correction before that row enters the production audience.

Check what stays out

A North heading alone is weak evidence. Inspect the figures and detail rows for North, then look for South data that should be absent. Repeat the same check for the South manager.

  
REQUIREMENTS AND LIMITATIONS

Check Prerequisites, Limits and Cost Before Choosing a Route

Native dynamic subscriptions require the report to be in a Premium or Fabric capacity workspace. The creator needs Build permission on the recipient semantic model and a Contributor, Member or Admin role in the report workspace. Guest users cannot create them. Check these prerequisites for the account that will own the subscription.

Requirement Native Power BI PBRS data-driven schedule
Recipient-specific view Maps recipient-model values to report filters; one value per filter. Uses driver records to supply report filter values.
Email details and attachments Can take recipients, subject and attachment choice from data. Full attachments must be smaller than 25 MB. Can drive delivery details and output formats from reporting records.
Destination Subscription email. Driver-based destinations can include email, disk and FTP; check the chosen output and destination together.
Audience and operation Up to 1,000 recipient rows, with capacity-backed rendering. Maintain and validate the driver, background data access and per-record results.
Cost Review capacity licensing, workload and ownership. PPU alone does not meet this feature’s capacity prerequisite. Include the PBRS license, report-source licensing and the operating environment.

The PBRS data-driven guide describes record-based filters, formats and destinations. Choose it for the delivery work you need, rather than assuming every personalized email requires another product.

Count rows before the run

The native limit is 1,000 recipient rows. Above that, only the first 1,000 receive emails and the subscription owner gets an error notification. Reconcile the intended audience before saving, rather than discovering missing managers afterward.

Check the report and mapping limits

Native dynamic filtering accepts single values. SSAS Live Connection is unsupported, as are report resolutions below 400 pixels. Renaming recipient-model tables or columns during processing can prevent filters from applying correctly.

Review capacity and external delivery

Rendering counts as interactive capacity activity. A PPU license is not the dedicated capacity this feature requires. External recipients also remain subject to the general subscription capacity and tenant rules; a dynamic mapping does not make trial or PPU workspaces eligible for external delivery.

Compare the whole running cost

Existing capacity may meet the native requirement, but it still has workload and ownership costs. PBRS is commercial software with its own operational needs. Include maintaining recipient data and investigating failures in either comparison; there is no universal savings figure for this example.

  
END-USER WORKFLOWS

Configure and Test the Two-Recipient Mapping

Start with two approved recipients. Confirm that the published recipient data contains their current addresses and nonblank Region values, then build the subscription:

  1. Open the standard report and choose Subscribe to report > Create a subscription > Dynamic per recipient. Select the recipient semantic model.
  2. In Select and filter data, choose the email and Region fields. Filter to the two test recipients and inspect the result. Check that aggregation has neither merged nor multiplied the intended rows.
  3. In Email details, choose Get from data for the recipient field. Set the subject, report page and preview or attachment choices. Use data-driven choices where needed.
  4. In Map your data, map the actual report Region field to the recipient Region value. Choose deliberately whether Include my changes supplies the starting view or the default report state is used.
  5. Review cadence, time zone, duration and active status, then save. Run a controlled test and inspect both received outputs for the right region, excluded region and reporting period.

For PBRS, choose Data-Driven > For Power BI Service > Reports & Dashboards. Build a SQL driver and use Parse to inspect its records, or enter a JSON driver and use Validate. Choose a unique Key Column or Row Identifier, then select the account, report and schedule.

In Report Filters, use Data-Driven Inserts to supply each record’s Region value. Configure the required format and destination from the driver, using the actual fields in your data. Preview representative records, then test delivery to the same two approved mailboxes. The PBRS wizard guide shows these settings.

Inspect the received reports

Compare North’s received figures with North’s source data and confirm South is excluded. Reverse the check for South. Keep both results with the mapping and report versions before expanding the audience.

Check the published mapping after changes

When a manager or Region code changes, update and refresh the recipient model or driver used by the job. Editing a local spreadsheet alone does not prove the running subscription has the new value.

Trace wrong data to the mapping first

If North receives South data, inspect field mapping, spelling, data type and the starting report state. For a missing email, first confirm that the recipient row exists and qualifies for the run, then investigate rendering and mail delivery.

Choose grouping deliberately in PBRS

If one mailbox has several approved records, PBRS can group reports by email address. That option disables embedding reports in the email body. Check the resulting attachments and destination before using it for the full audience.

  
DEVELOPER AND API WORKFLOWS

Validate Records and Investigate Each Delivery

Validation of North and South recipient records against their intended regional reports.

A batch success alone does not prove each person received the right data.

Optional technical section. A developer or administrator can make the recipient data easier to validate and investigate. Give each approved record a stable identifier and retain the version used for each reporting run.

Illustrative driver checks
recordId: unique and nonblank
email: approved controlled recipient
region: exactly one approved report value
enabled: approved for this reporting run
rowCount: reconciled with the intended audience
baseView: documented saved/default report state
acceptance: correct included region and excluded region
changeReview: recipient/model field rename or mapping refresh

This is a validation specification, not executable PBRS syntax. Implement and test the checks in the recipient-data process. Neither a saved schedule nor a successful overall job proves that every recipient received the correct report.

Test background access

For ODBC-based SQL drivers, PBRS recommends a System DSN so it remains available when the configuring user logs off. The unattended service identity needs the required database access. A successful interactive connection does not establish that the background run can read the driver.

Reject missing or unapproved values

Configure the data process to reject a blank Region, invalid value or unapproved mailbox before delivery. Do not replace a failed mapping with an unrestricted report. These checks need implementation; they are not an automatic promise that PBRS blocks every bad record.

Reconcile outputs with records

Keep the driver identifier, expected Region, run reference and generated file or message reference together. Match the expected records with the actual results, and investigate missing or failed records individually.

Retest changes that affect scope

A renamed field, revised mapping or changed starting view can alter a manager’s output. Review these changes as reporting changes and repeat the two-region test. Use the current model and destination settings rather than guessed insert syntax.

  
CHOOSE YOUR NEXT STEP

Choose the Route and Approve the Mapping Together

Choose native dynamic subscriptions when personalized email, single-value filters and the recipient limit fit your requirement. Maintain the recipient model and account for its capacity workload.

Choose PBRS when approved records need to drive filters, formats and destinations together. Confirm licensing and unattended driver access, then keep results tied to each record.

For the regional example, the next step is the same with either route: test two real, approved mailboxes and inspect both received reports before expanding the audience. The workflow here is illustrative; no live Power BI delivery test has been performed.

Explore Power BI Report Automation. Technical sources reviewed: 9 October 2026.

Considering PBRS for data-driven report delivery? Share the guide with your colleagues to review deployment, licensing, security and your reporting requirements.

Download the PBRS Internal Evaluation Guide

Contributors:

Christian Ofori-Boateng

Christian Ofori-Boateng

CEO, ChristianSteven Software