Ability to define rules at column level, to control the data fields available to different roles (e.g. employee salary visible to the users in finance roles only, while other employee details visible...
This item should not be marked Completed. It should be marked Rejected, Not Planned, or another status that clearly indicates the requested functionality is not currently available and is not expected in the near term. Unless I'm missing something, there does not appear to be a way to implement the requested functionality without building and maintaining a custom security framework on top of a platform that is marketed as an enterprise analytics solution. The requirement is straightforward: apply column-level security at the data layer and allow reports to continue functioning for users who do not have access to the secured columns. Securing a column should not cause report visuals to fail or require developers to create duplicate reports, duplicate semantic models, custom DAX-based security logic, or security lookup tables. In my experience, enterprise BI platforms are expected to provide security that carries through from the data source to the presentation layer without requiring significant custom development. When a user lacks access to a column, the reporting layer should be able to gracefully handle that condition rather than breaking visuals that reference the secured data. Current workarounds appear to involve custom security tables, user/group mapping tables, measure-based security logic, or maintaining separate models and reports for different audiences. These approaches increase complexity, increase maintenance effort, and introduce additional opportunities for configuration errors. Also introduces additional security concerns. The requested functionality is not a niche use case. It is a common enterprise requirement to present a single report experience to different audiences while enforcing column-level security on sensitive financial or operational data. If this scenario is not planned for Fabric, the community would benefit from clear guidance stating that the intended design is to use separate semantic models, separate reports, or custom security logic rather than relying on column-level security to provide an adaptive report experience.
