Prevent Overwriting Subscription Parameters When Adding Report Parameters

Summary: Currently, when a paginated report is republished with a new parameter, making any subscription changes (e.g., adding or editing one) overwrites all existing subscriptions' parameter values to match the newly edited subscription. This behavior introduces risks of data breaches, unintended report emails, and loss of previously configured parameter values. An alternative approach is needed to preserve existing subscription configurations when adding new parameters.

The current concerning UX flow:

• Create a new report in the latest version of Power BI Report Builder with at least one parameter.
• Deploy the report to the Power BI Service
• Create one or more subscriptions for the report, setting the parameter value for the subscription(s)
• Add a new parameter to the report and deploy the report. Do not specify a default value for the new parameter.
• View the report, and select Subscribe to report.
• Select New Subscription, enter details to configure the new subscription
• Select Save

Observe that all subscriptions have had their values set to those of the new subscription. Screenshots of this process are at https://i.imgur.com/eWHq8R6.png

When performing the first change to a report’s subscriptions after adding a new parameter, either by adding a new subscription or updating an existing subscription, all existing subscriptions enter a state where their subtitle has a light yellow “Unsaved changes” label, and the parameters section states “To save this subscription, return to the report and set all required parameter values.”.

I believe this text is intended to communicate that subscription details need updated, however I believe the behaviour is significantly unintuitive and has significant risk. Here’s why:

• It forces a behaviour against natural UX flow: After adding a report parameter, the first change I would usually make is adding a new parameter, using the flow above. I would not expect to be making any changes to existing subscriptions at this point.
• It forces all subscription parameters be overwritten with a single set: I cannot understand the current intended flow - each subscription usually has different parameter values, so forcing me to overwrite the parameters for all subscriptions to a single set of values is nonsensible.
• It removes the previous values, making it difficult to recreate subscription parameters: The overwriting of distinct subscription parameters (which typically vary for each recipient) removes the original values, complicating recovery and increasing the likelihood of errors.

In addition to the above UX concerns, I also have these concerns:

• The current state guides users in a direction that has strong likelihood to result in a security breach: report subscriptions for paginated reports rely on parameter values to refine the information to display, and whether to show or hide certain information for each subscription. Paginated report subscriptions also allow external (B2B) recipients (depending on tenant configuration).
• By having all subscription parameters be overwritten with those of the first subscription update after a report parameter has been published, the current state puts all subscriptions in both an active state and with misconfigured report parameters. As report subscriptions are performed with the semantic model permission sets as the person who configured them, RLS within the model would not stop the above fail state from occurring.
• This results in external users seeing the information that the report author may not have intended them to receive (due to parameter-based filtering or visibility expressions).
• The current state guides users in a direction that is likely to result in recipients being sent information that they are not intended to receive: where multiple subscriptions are set up with different parameters for the same recipient, the point-in-time snapshot of the report sent in the attachment is irrelevant for the specific recipient (whose subscription was previously configured with more relevant settings).

Because report subscriptions are scheduled in advance, it may be some time between configuration of the report subscriptions and recipients receiving the erroneous datasets attached to the subscription.

The current state gives me concern regarding the team’s perspective on user production configuration data. By considering it suitable to overwrite (corrupt/delete/clear) existing report configurations as a result of a somewhat-disconnected change (adding a parameter to a report), experiencing this issue overwrite several report subscriptions has damaged my trust in the intuitiveness of the system.

Alignment with wider Power BI: I believe the current state reuses the flow used by subscriptions for [interactive] Power BI reports, as the subscription pane appears the same for both report types. For interactive reports, having a single [Save] button at the bottom of the subscription list makes sense. However, for paginated reports, where each subscription shows potentially different data to different recipients, the paginated report flow seems closer to the Manage access > Grant people access flow, with a separate “dialog” and save button per subscription.

Recommendation: I suggest the behaviour be modified to disable report subscriptions with invalidated parameters, requiring the additional parameters be set, or all parameters for the subscription be reset if per-parameter revalidation is not possible - in this case displaying the previous [now invalid] parameter value(s) for reference when re-setting these.

It would also be helpful if a “report subscription disabled” notification email were sent to the owner of any subscriptions that became invalid due to a report parameter adjustment, notifying the owner that their subscription was now disabled and needed manual review, in a similar behaviour to when a scheduled refresh is disabled.

Although this specific implementation is a suggestion, any alternative that avoids bulk overwriting a report’s subscription’s parameters when a report parameter change takes place would be appreciated.

Lesser solutions could be showing a publish impact dialogue notification in the paginated report publish flow indicating that report parameters would require their permission sets be updated, and/or adding a warning prompt dialog warning of the number of subscriptions having their parameters updated to the current parameters when selecting the [Save] button on the paginated report subscription pane on the first save after publish.