What's the best practice when one needs to add columns to the data table behind a visualization?

[frost789]

In my old visualization (see picture below) I have various varibles (eg withdraw numbers, fail numbers) for the past years (Fall 2022, Fall 2023, Fall 2024). However, for Fall 2025, I need to add a few new variables (eg major code, degree code) for the Fall 2025's visualization. I will continue to use the visualization layout below. What's the best practice under this scenario? As I don't have "major code", "degree code" variables for Fall 2022, Fall 2023, Fall 2024, but will have those new variables from Fall 2025 and on. I plan to use major code, degree code in my Fall 2025 visualizations and future visulizations, but will probably have N/A for prior years (Fall 2022, Fall 2023, Fall 2024). 

 

[v-ssriganesh]

Hi @frost789,

Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to @MasonMA, @Zanqueta, @krishnakanth240 & @Ashish_Mathur for sharing valuable insights.

Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.

Thank you for being part of the Microsoft Fabric Community.

[Zanqueta · Accepted solution]

Hi , @frost789
The recommended solution is to:

• Add the new fields to your existing fact table.
• Allow earlier years to contain nulls for those fields.
• Preserve the same data structure across historical and future periods.
• Manage the visibility of new attributes in visuals where appropriate.

This approach ensures a clean, maintainable, and scalable data model.

[krishnakanth240]

Hi @frost789 

Your core table (facts like withdrawals, fails, enrollments) should remain one table across all years. For the new attributes (Major Code, Degree Code), you can add the columns to the fact table, populate them only from Fall 2025 onward, and leave them as NULL / BLANK for earlier years

[MasonMA]

Hi, 

If your new variables are descriptive attributes, i'd suggest modelling them as dimension tables and relate them to the fact table.

For Fall 2022–2024, map rows to a single “Unknown” member; from Fall 2025 onward, populate the real values.

This keeps the model scalable, avoids sparse fact tables, and allows the same visuals to continue working without redesign.

If introducing dimensions is not feasible, adding nullable columns to the existing fact table like user above mentioned is still acceptable, but just avoid hard-coding text like 'N/A' and rely on BLANK() instead.

[frost789]

Thank you for your answer. Can you provide an example as to how I should rely on BLANK() instead of "N/A"? Other answers seem to suggest it's ok to use "N/A" or NULL for those years missing new variables.

[MasonMA]

In Power BI, BLANK() / NULL means “unknown or not applicable”, whereas "N/A" is just a real text value.

Because "N/A" is a value, Power BI treats it as legitimate data, not missing data.

[Ashish_Mathur]

Hi,

Just add those columns in your table.  That should not break anything.  For Spring 2025, the visuals for those 2 columns will just appear blank.

[frost789]

I don't follow. The dashboard doesn't have Spring data. Only Fall data.