Title: Dynamic subscription sends extra report emails when a link-only subscription is added.

Hi VishalSharma-71,

I think you're running into a side effect of sharing one recipient semantic model across multiple dynamic subscriptions. This behaviour is consistent, but seems really buggy to me nonetheless. 

When any subscription runs, Power BI evaluates the recipient model you selected in that subscription and uses its columns to decide who gets an email, what the subject is, and whether to attach a PDF or send a link. The product docs show that behavior (email details, attachment selection, and the “Link to report in Power BI” toggle are all driven from the same recipient model), but they do not guarantee isolation by report if the same model feeds multiple subscriptions (docs, see “Email details” and “Considerations and limitations”). The same pattern exists for paginated reports (docs).

SOme options I would try:

1. Give each report its own recipient table/view (or its own semantic model).
2. Or, keep one model but partition it logically and hard-scope each subscription to a unique slice in the wizard’s Select and filter data step (not only in “Map your data,” and not only by turning dynamic filters on/off).

If you want to keep a single shared model, I recommend:

• Add a column like SubscriptionKey (e.g., ReportA, ReportB, ReportC) and filter on that in the subscription’s Select and filter data step.
• Avoid using a single row set where AttachmentType, EmailSubject, etc. differ across reports without also scoping by SubscriptionKey.
• Prefer a dedicated table or view per report inside the same model (e.g., Recipients_ReportA, Recipients_ReportB) so each subscription points at its own table in the Select and filter data step.

Answers to your specific questions

1. Is this expected by design? There is no explicit doc stating runs are isolated by report when sharing a recipient model. Practically, evaluation is model-scoped for the subscription that runs, so rows not strictly filtered out can be picked up. So the behavior is explainable and avoidable, but not clearly documented as “by design.”
2. Official guidance or docs? The docs cover how the recipient model drives recipients, subjects, and attachments and how the Link to report toggle works, but they do not describe cross-triggering behavior. See: Dynamic per recipient subscriptions for reports.
3. Best practices to prevent cross-triggering (without splitting models):
   • Add a SubscriptionKey column and filter to it in Select and filter data.
   • Use distinct tables or views per report inside the same model and select the right table during setup.
   • Keep attachment/link-only settings consistent within each key.
4. Roadmap for link-only respecting schedules without touching other rows: Nothing public in docs at the moment. For tenant-specific confirmation, open a Microsoft support ticket and include your Cluster URI and recent Activity IDs from the email headers.

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

Hi tayloramy ,
Thank you for the detailed explanation and the alternate solutions. I just need one clarification. My current recipient CSV already includes the following columns: IsLiveSubscription, ReportName, Frequency, Day, Time, DateRange, LocationName, IsToday, EmailSubject, and RecipientEmail. Each report name and its related details are already separated within this file.

However, this issue occurs only when I configure the subscription to send only the link (no attachment or PDF). All other dynamic subscriptions that send PDF attachments are working correctly. Could you please share some insights on why this behavior happens only for link-only subscriptions?

Thank you.

Hi All, thankyou for providing different approaches but not sure why this is not working and even I connected with the microsoft, they are also not sure about it. So for that particular report where i am faced the issue that one i switched back to Standard Subscription and that is working fine.

Hi VishalSharma-71 

The behavior you’re observing with dynamic per-recipient subscriptions in Power BI Service — where running a link-only subscription triggers unexpected emails from other reports sharing the same recipient dataset — is not officially documented but appears to stem from the way Power BI currently handles shared recipient dataset evaluations across multiple dynamic subscriptions. When multiple subscriptions (like your Reports A, B, and C) reference the same recipient dataset, Power BI treats that dataset as a shared evaluation context at runtime. In practice, when one subscription runs — especially a link-only one without a dynamic filter or attachment — the service can re-evaluate the full dataset for all linked subscriptions rather than isolating only the rows related to the scheduled report. This behavior effectively causes cross-triggering, where other subscriptions using the same dataset are included in the evaluation pipeline, leading to additional unintended emails.

This is not clearly stated in Microsoft’s current documentation, and as of now, there’s no public roadmap feature addressing this overlap. However, your findings — that isolating each report with its own dedicated recipient dataset prevents the issue — align with what appears to be the current best practice: avoid sharing the same recipient dataset across mixed subscription types (especially between PDF and link-only formats). Each subscription should ideally have its own recipient source to maintain isolation and prevent shared evaluations.

This cross-triggering seems to be a by-design limitation of how Power BI batches dynamic subscription evaluations when a shared dataset is used. Until Microsoft introduces finer control or isolation logic in the dynamic subscription engine, the recommended workaround is to separate recipient datasets per report or ensure that all subscriptions referencing a shared dataset use the same delivery type (e.g., all PDFs or all link-only). This prevents Power BI from reprocessing the dataset globally and sending unintended notifications during mixed-type schedule runs.