I’m evaluating different approaches for implementing data security in visualization dashboards. The debate is between role-based widget visibility (hiding entire widgets/sections based on roles) versus row-level data filtering (showing the same widgets but filtering the underlying data by user permissions).
We have a multi-tenant manufacturing dashboard where different customers should see only their equipment data, and within each customer, different user roles (operator, supervisor, manager) need different levels of detail. I’m concerned about scalability and performance implications of both approaches.
What are the pros and cons of each approach? How do they scale with large numbers of users and data volumes? Are there hybrid patterns that work well?
Performance concerns with row-level filtering are valid but manageable. The key is using indexed queries and caching strategies. Store user-to-data mappings in fast lookup structures (InfoTables indexed by user ID). When a service executes, do a quick lookup to get the user’s allowed data scope, then use that in a WHERE clause.
For very large datasets, implement data partitioning at the Thing level. Create separate Thing groups per customer/tenant, then security becomes about granting access to specific Thing groups rather than filtering rows.
Row-level filtering is more flexible and scales better. You maintain one mashup design but filter data at the service level based on user context. This is easier to maintain than multiple mashup variants, and it allows for more granular control. Users can have the same UI experience but see different data subsets.
The key is implementing the filtering at the Thing service level, not in the mashup. Every data service should check the current user’s permissions and automatically filter results.
The maintenance overhead of multiple mashup variants is a real concern. We have about 8 different role types currently, and that could grow. Managing 8+ mashup variants seems problematic. But I’m also worried about the performance of filtering large datasets at runtime for every user request.
Why not use both? Implement row-level filtering for data security (that’s your security boundary), then use role-based visibility for UX optimization. For example, operators see simplified dashboards with fewer widgets, while managers see comprehensive views with all analytics - but both are backed by the same data services that filter appropriately.
This gives you security through data filtering plus optimized UX through role-based layouts. Best of both worlds.