10.2 Subscriptions, Alerts, and Semantic Model Refresh

Quick Answer: Subscriptions email a report/page snapshot (PDF, PowerPoint, or link) on a schedule or after refresh, with optional pre-set filters. Data alerts notify when a dashboard tile (card, gauge, or KPI only) crosses a threshold. Scheduled refresh keeps Import data current — 8x/day on Pro, 48x/day on Premium/PPU/Fabric. Incremental refresh partitions data by date (via RangeStart/RangeEnd) so only recent partitions refresh, keeping refresh fast as data grows.

Email subscriptions

Open a report -> Subscribe to report. Each subscription is independent, so one report can have several with different filters and schedules.

After data refresh sends only when the dataset actually refreshes — ideal when timing should follow data availability rather than a clock.

Data alerts

Data alerts live on dashboard tiles built from card, gauge, or KPI visuals (never on charts, tables, or reports). Configure via the tile's More options -> Manage alerts -> Add alert rule: a condition (Above/Below a threshold) and a notification cadence (e.g., at most once an hour / once a day).

• Alerts are checked only when the data refreshes — they do not poll continuously.
• Notifications arrive via email and the notification center.
• You can trigger a Power Automate flow when an alert fires (e.g., post to Teams, create a ticket).
• Limit: up to 250 alerts per user.

Scheduled refresh

Configure under Semantic model -> Settings -> Refresh -> Scheduled refresh (frequency, time slots, time zone, failure notifications). Refresh limits by license:

Exam staple: Pro = 8 scheduled refreshes/day; Premium/PPU/Fabric = 48. The 8-refresh quota on shared capacity resets daily. (Higher cadence is possible only via the XMLA endpoint / API on Premium.)

Refresh types: full (reload everything), incremental (only changed partitions), on-demand (manual), and API/Power Automate-triggered. Monitor under Refresh history (start/end, duration, status, error detail).

Incremental refresh

Incremental refresh keeps refresh duration roughly constant as data grows, because only recent partitions reload.

Step 1 — parameters. In Power Query, create two parameters named exactly RangeStart and RangeEnd, both Date/Time (these reserved names are required).

Step 2 — filter the table using them:

Table.SelectRows(Source, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)

Step 3 — policy. Right-click the table -> Incremental refresh: set Archive data for the last N years/months and Incrementally refresh the last N days/months. Optionally enable Detect data changes (only refresh partitions where a watermark column changed) and Only refresh complete periods.

After publishing, the service creates date-based partitions automatically and refreshes only those in the incremental window; archive partitions stay loaded. Note the key exam fact: you configure incremental refresh in Desktop, but partitioning only happens after you publish to the service — in Desktop the parameters simply filter the data.

Detect data changes and "only refresh complete periods"

Two incremental-refresh options deserve their own treatment because they change behavior meaningfully. Detect data changes adds a poll-column step: instead of blindly refreshing every partition in the incremental window, Power BI checks a max(LastModified) watermark per partition and refreshes only partitions whose watermark actually moved — so a refresh that would touch the last 10 days might reload just the 2 days that changed. Only refresh complete days/months prevents loading a partial current period (e.g., it won't load a half-finished current month), which keeps period-over-period comparisons clean.

Both are optional toggles in the incremental-refresh policy dialog.

Refresh failures: the troubleshooting order

The exam frequently presents "scheduled refresh fails — why?" Work the likely causes in order: (1) expired or wrong credentials on the data source (the most common cause — re-enter them in dataset settings); (2) a missing or offline gateway for on-premises sources; (3) a timeout because the refresh exceeded the duration cap (2 hours on Pro, 5 hours on Premium); (4) a source schema change (renamed/removed column) that breaks a query step; or (5) capacity throttling on an overloaded Premium capacity.

Failure notifications can be routed to the dataset owner and additional specified addresses, and Refresh history gives the exact error.

Alerts, subscriptions, and Power Automate

Know how the three notification mechanisms differ. A subscription pushes a snapshot on a schedule. A data alert pushes a notification when a tile value crosses a threshold (checked only at refresh). A Power Automate flow can be triggered by a data alert to do something richer — post to a Teams channel, create a ticket, send a templated email to a distribution list, or even write back to a system. So "notify the on-call team in Teams when inventory drops below 100" is a data alert + Power Automate pattern, not a subscription.

On the exam

Frequent items: choose a subscription (weekly, PDF, region filter) for scheduled delivery; recall that data alerts require card/gauge/KPI dashboard tiles and can trigger Power Automate; recall 8 (Pro) vs 48 (Premium/PPU/Fabric) refreshes/day and the 2h/5h duration caps; name the RangeStart/RangeEnd Date/Time parameters for incremental refresh; and know Detect data changes refreshes only partitions whose watermark moved.