Subscriptions, Alerts, and Semantic Model Refresh

Quick Answer: Subscriptions email report snapshots on a schedule. Data alerts notify when dashboard values cross thresholds. Scheduled refresh keeps data current (8x/day Pro, 48x/day Premium). Incremental refresh only refreshes new/changed data for faster, more efficient refresh cycles.

Email Subscriptions

Creating a Subscription

Open report → Subscribe (envelope icon)
→ Configure: Name, recipients, frequency, page, format

Subscription Settings

Subscription Behavior

• Emails are sent even if data hasn't changed (unless configured after refresh only)
• "After data refresh" trigger sends the email only when the dataset has refreshed
• Filters applied to the subscription persist in the delivered snapshot
• Each subscription is independent — one report can have multiple subscriptions with different filters

Data Alerts

Creating Data Alerts

Data alerts are available on dashboard tiles (not reports) for card, gauge, and KPI visuals:

Dashboard → Hover over tile → More options (...) → Manage Alerts
→ Add Alert Rule:
   - Condition: Above / Below
   - Threshold value
   - Notification frequency: At most once an hour / At most once a day / At most every 24 hours

Alert Behavior

• Alerts check values only when data refreshes
• Notifications sent via email and the Power BI notification center
• Optional: Trigger a Power Automate flow when an alert fires
• Maximum 250 alerts per user

Alerts vs. Subscriptions

Scheduled Refresh

Configuring Scheduled Refresh

Power BI Service → Workspace → Dataset → Settings → Scheduled Refresh
→ Configure: Frequency, time slots, time zone, notifications

Refresh Limits

Refresh Types

Monitoring Refresh

Workspace → Dataset → Refresh History

Shows:

• Start/end time of each refresh
• Duration
• Status (success, failure, cancelled)
• Error details for failures
• Rows transferred

Incremental Refresh

Why Incremental Refresh?

Setting Up Incremental Refresh

Step 1: Create RangeStart and RangeEnd parameters

In Power Query Editor, create two parameters:

• RangeStart: Type = Date/Time, Default = earliest date
• RangeEnd: Type = Date/Time, Default = latest date

Step 2: Filter data using the parameters

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

Step 3: Configure the policy

Right-click table in Model view → Incremental Refresh
→ Archive data: Store data for the last N years/months
→ Incrementally refresh: Refresh data in the last N days/months
→ Optional: Detect data changes (only refresh if source changed)
→ Optional: Only refresh complete days/months

How It Works in Production

After publishing to the Power BI Service:

1. Power BI creates date-based partitions automatically
2. During refresh, only partitions in the "incremental" window are refreshed
3. Older partitions in the "archive" window are NOT refreshed (already loaded)
4. New partitions are created as time progresses

Exam Tip: Incremental refresh is configured in Power BI Desktop but only activated after publishing to the Power BI Service. In Desktop, the parameters filter normally — partitioning happens in the Service.

On the Exam

The PL-300 frequently tests:

• Configuring subscriptions with filters and schedules
• Setting up data alerts on dashboard tiles
• Understanding refresh limits by license type
• Configuring incremental refresh with RangeStart/RangeEnd
• Troubleshooting refresh failures (credentials, gateway, timeout)