This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Model the data (25–30%)
--> Design and implement a data model
--> Configure Table and Column Properties
Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.
Configuring table and column properties is a critical step in designing a clean, intuitive, and performant Power BI data model. While these settings may appear cosmetic at first glance, they directly influence usability, accuracy, performance, and user experience — all of which are assessed on the PL-300: Microsoft Power BI Data Analyst exam.
Why Table and Column Properties Matter
Properly configured properties:
- Make reports easier for business users to navigate
- Reduce confusion and misuse of fields
- Improve DAX readability and maintenance
- Prevent incorrect aggregations
- Support star schema best practices
On the exam, Microsoft frequently tests why and when to configure properties — not just where the settings are located.
Table Properties
Table Name
- Should be descriptive and business-friendly
- Avoid technical or source-system names
Good examples:
FactSalesDimCustomer
Poor examples:
tbl_sales_v2Query1
Exam Tip: Clear naming improves self-service reporting.
Table Description
- Used for documentation
- Appears as tooltips in Power BI Service
- Helps report consumers understand table purpose
Table Visibility (Hide/Show)
- Hidden tables remain in the model but are not visible in the Fields pane
- Commonly used for:
- Bridge tables
- Technical helper tables
- Date tables used only for relationships
Important: Hiding does not improve performance — it only affects usability.
Column Properties
Column Name
- Use business-friendly terminology
- Avoid abbreviations unless widely understood
- Remove underscores and technical prefixes
Column Description
- Explains the meaning of the column
- Appears as a tooltip
- Valuable in shared datasets and Power BI Service
Data Type
Choosing the correct data type is foundational:
- Impacts aggregation
- Affects relationship behavior
- Influences performance and compression
Examples:
- Dates → Date or Date/Time
- IDs → Whole Number or Text (depending on source)
- Currency → Decimal Number
Default Summarization
Controls how numeric columns aggregate by default.
Common options:
- Sum
- Average
- Min / Max
- Count
- Do not summarize
Best Practice:
- Disable summarization for:
- IDs
- Keys
- Percentages
- Rates
Exam Insight: Misconfigured summarization is a common exam trap.
Format
Determines how values display in visuals.
Examples:
- Currency
- Percentage
- Decimal places
- Date formats
Formatting improves readability and consistency across reports.
Sort By Column
Used when a column’s natural sort order is not alphabetical.
Common use cases:
- Month Name sorted by Month Number
- Day Name sorted by Day of Week
PL-300 Tip: Sort By Column is frequently tested.
Column Visibility
- Hide columns not intended for report authors
- Common examples:
- Surrogate keys
- Technical IDs
- Relationship-only columns
Special Column Properties
Data Category
Informs Power BI how to interpret data, especially for maps.
Examples:
- City
- Country/Region
- Latitude / Longitude
- URL
Correct categorization improves map accuracy and link behavior.
Summarize Across Tables
Controls whether a column can be aggregated across relationships.
- Typically enabled for measures
- Rarely changed for standard columns
Properties and the Star Schema
In a well-designed star schema:
- Fact tables:
- Numeric columns summarized
- Foreign keys hidden
- Dimension tables:
- Descriptive columns visible
- Primary keys hidden
- Sorted attributes configured properly
These property settings reinforce proper analytical usage.
Impact on the Data Model
Correct configuration:
- Prevents incorrect totals
- Improves DAX clarity
- Simplifies report authoring
- Reduces user errors
Poor configuration leads to:
- Summing IDs
- Confusing field lists
- Incorrect visual behavior
- Increased support questions
Common Mistakes (Often Tested)
❌ Leaving default summarization on ID columns
This results in meaningless totals.
❌ Not configuring Sort By Column
Causes incorrect ordering in visuals.
❌ Exposing technical columns to report users
Leads to misuse and confusion.
❌ Using inconsistent naming conventions
Makes models hard to understand and maintain.
Best Practices for PL-300 Candidates
- Use business-friendly names
- Hide keys and technical columns
- Disable summarization for non-additive values
- Always configure Sort By Column when needed
- Add descriptions for shared datasets
- Validate formatting and data categories
How This Appears on the PL-300 Exam
You may encounter questions like:
- Why are totals incorrect in a visual?
- Why are months sorting alphabetically?
- Which columns should be hidden from report view?
- What property controls default aggregation?
The correct answer often involves column properties, not DAX.
Quick Decision Guide
| Requirement | Property to Configure |
|---|---|
| Prevent summing IDs | Default Summarization |
| Correct month order | Sort By Column |
| Improve map visuals | Data Category |
| Hide technical fields | Column Visibility |
| Improve usability | Names & Descriptions |
Final PL-300 Takeaways
- Table and column properties shape how users interact with data
- Defaults are rarely optimal
- Proper configuration prevents errors before they happen
- This topic is high-value on the exam
- Most fixes do not require DAX
Practice Questions
Go to the Practice Exam Questions for this topic.
The Data Community 
One thought on “Configure Table and Column Properties (PL-300 Exam Prep)”