PL-300 — Frequently Asked Questions

Import meets the daily 7 AM refresh requirement and uses the in-memory VertiPaq engine for fast visual interactions, while DirectQuery sends queries to source systems.

Yes, DirectQuery supports row-level security, but the Northwind Traders case still favors Import (C) for daily refresh and faster visualization response.

Dual mixes Import and DirectQuery per table only for DirectQuery-heavy models, and live connection connects to an external published model, not a new semantic model from multiple sources.

No. It queries Boards work item data directly and cannot consume user-defined Analytics views, which is exactly why the OData Feed connector (D) is required here.

OData queries is not an actual Power BI connector name, so it is a purpose-built distractor. Analytics views are only consumed through the OData Feed connector.

It targets an on-premises Azure DevOps Server deployment, which contradicts the requirement to filter data from the cloud.

Power BI stores and queries data case-insensitively, so DirectQuery case-sensitive values can surface as undefined until casing is normalized in the source query or Power Query Editor.

Yes, the proposed solution (A) is Microsoft's documented remedy for undefined values caused by case-sensitive DirectQuery data, so no other change is required for the casing issue.

Option B would only be defensible if the solution changed column data types or removed column profiling; those actions diagnose or miss the casing issue rather than resolve the undefined values.

The index key keeps each row uniquely identifiable after casing is normalized, so the case-insensitive DirectQuery engine no longer collapses case-sensitive values into undefined results or errors.

No. The documented remedy pairs casing normalization with an index key; neither part alone is sufficient for DirectQuery over a case-sensitive source.

No, the scenario permits changing the data source. Adding the index key and normalizing casing there matches the official Microsoft guidance for this issue.

OneDrive for Business is backed by SharePoint Online, so the SharePoint folder connector refreshes without a gateway, unlike a local Folder path that needs one.

No. The Excel Workbook connector uses the local file system in Desktop, so refreshing in the service requires an on-premises data gateway.

Text/CSV cannot consume a binary .xlsx workbook, so it fails on capability before refresh is considered. Use Web or SharePoint folder instead.

Use Transform > Date > Year > Year menu path. This applies the Date.Year function automatically.

Splitting requires multiple steps and type changes. It fails the minimize administrative effort requirement compared to direct transform.

No, model-level aggregations summarize data after it has already been transferred through the gateway during refresh.

Apply filters or aggregations at the source using query folding in Power Query so less data is pulled into the model.

No, automatic page refresh applies only to DirectQuery storage mode and does not affect data imported via the gateway.

Reduce query frequency by optimizing DAX measures or using incremental refresh instead of frequent full imports.

Deleting high-cardinality, unused columns like TransactionID reduces row count memory usage without affecting monthly aggregation needs.

Yes, you can derive MonthStartDate from TransactionDate within the grouping step to avoid adding extra columns that increase model size.

PREVIOUSYEAR returns all dates from the entire previous calendar year, while SAMEPERIODLASTYEAR returns only the corresponding dates from the previous year based on the current filter context.

The filter sets the last date in the context (e.g., May 9, 2024). PREVIOUSYEAR then expands to include every day of the prior year (2023), summing all matching rows regardless of the specific filtered date.