Skip to main content
Question

Tabular Model IFS Cloud- Custom Field data shows up in SQL but no data in Power BI?

  • May 11, 2026
  • 3 replies
  • 44 views

Forum|alt.badge.img+7

Hello,

 

I have made a Custom Field on a tabular model table and while the data shows up when I run it in SQL but when I go to add it to the Power BI report, the field is there but no data populates for that field. Any suggestions to get data to populate in Power BI as well? I’ve ran a data load and did a “Full” Process Definition refresh for my tabular model as well.

 

Thanks,

Jay

3 replies

ashen_malaka_ranasinghe
Hero (Employee)
Forum|alt.badge.img+13

Hi ​@jayoneil98,

This behavior is typically not a data load or refresh issue, but rather a tabular model modelling problem between the source, the model, and Power BI. Since your custom field already returns values in SQL and the model has been fully processed, the issue is occurring after data retrieval at the semantic model layer.

In most cases, this happens because the field is either not fully integrated into the tabular model structure or is being filtered out by relationships in the model. Even though the column exists and is visible in Power BI, if it is not properly included in the tabular model’s metadata (for example, not correctly added to the table definition or partition query), Power BI can expose the column but still return blanks. Similarly, if the field participates in a relationship especially on the “one” side of a many‑to‑one relationship any nulls or mismatched keys will cause Power BI to return blank values, even though data exists in the underlying source.

Another frequent cause is that the data is not correctly flowing through the analysis model pipeline (Information Source → Data Pump → Tabular model). In this scenario, the SQL you tested might not be the exact dataset that the tabular model is using. If the custom field was added at the database level but not properly propagated into the Information Source or tabular model definition, the model will not actually hold the data, despite appearing to do so.


Forum|alt.badge.img+7
  • Author
  • Hero (Customer)
  • May 12, 2026

Hi ​@ashen_malaka_ranasinghe 

 

Thank you for your response! I have been doing some experimenting and have gotten some better success when using the tables and function calls that utilize the tables rather than the views. Starting to iron out and document a process on customizing existing tabular models and tabular tables. Out of curiosity, is there a way to get the data to populate with the views? Would it not populate due to the Row Level Security implemented on the views rather than the tables? I’m just curious if it would work with views but maybe would tables be better suited for BI reporting? Thank you. 

 

Thanks,

Jay


ashen_malaka_ranasinghe
Hero (Employee)
Forum|alt.badge.img+13

Hi ​@jayoneil98,

Yes, it is possible to use views as data sources for BI reporting, and in practice (especially in IFS and Power BI-based architectures) both tables and views are supported equally as long as the consuming account has the required SELECT access. In fact, BI data pipelines (such as Analysis Models) explicitly allow sourcing from “any Table or View” when the appropriate permissions are in place

However, the behavior you’re observing is very likely related to Row Level Security (RLS) rather than the use of views themselves. RLS introduces an additional filtering layer on top of your data access, meaning that even if a view returns data at the database level, the BI model or reporting layer may still restrict or completely filter out rows based on the user context or role definitions. This is why data may appear “empty” or partially populated RLS is actively applied after the data source is queried, not just at the base table level.

When it comes specifically to views, there are a couple of nuances:

  • If RLS is implemented only at the table level, but your view abstracts or joins those tables without preserving the security context, you may get inconsistent or unexpected results.
  • If RLS needs to be enforced through views, it often requires explicit design or annotations to ensure the view is “RLS safe” and does not unintentionally expose or hide data.

From a BI design perspective:

  • Views are generally preferred when you want to encapsulate business logic, simplify joins, or provide a stable semantic layer for reporting.
  • Tables (or staging tables) may be better suited when performance, large scale transformations, or incremental loading is important especially in data lake or warehouse scenarios.