Data Level Security in Bold BI: Understanding and Implementing Row-Level Access

Introduction to Security in Bold BI

Security in Bold BI is designed with a layered approach to ensure that users can access only the information they are authorized to view, both in terms of accessible content and the data within it. Security is a critical aspect of any software, and Bold BI provides key features such as authentication, authorization, data security, network security, and more to safeguard customer data.

This framework is categorized into two main levels:

• Object-Level Security: Controls access to BI assets such as dashboards,data sources, and categories. It governs whether a user can view, edit, or manage these items.

• Data-Level Security: Controls the rows of data a user can access within a dashboard. This includes Row-Level Security mechanisms that dynamically filter data based on the user’s role, group, or context.

Object-Level Security in Bold BI

• Object-Level Security determines what a user can access or manage within the Bold BI environment. It is primarily focused on granting or restricting visibility and interaction with objects like dashboards, data sources, and categories.

• Permissions such as read, write, create, and delete are granted to users or groups. For example, without read permission, a user won’t be able to view a dashboard at all, regardless of data-level rules. This acts as the first layer of security that protects against unauthorized access to assets.

• This layer is most effective when controlling access to content types for instance, showing specific dashboards only to a department, or restrictingediting rights to a set of power users. While it doesn’t deal with data filtering within dashboards, it forms the foundation upon which Row-Level Security is built.

Data-Level Security and Row-Level Filtering

• Data-Level Security refines access by enforcing restrictions on the data itself, rather than the dashboards or objects. This is where Row-Level Security becomes key. Instead of building and maintaining multiple dashboards for each user type, a single dashboard can be shared with different users, and Row-Level Security ensures each sees only their permitted rows.

• The benefits of Row-Level Security go beyond security. It reduces design redundancy, eases maintenance, and supports scaling to thousands of users with varying access needs. When paired with proper user or group segmentation, Row-Level Security makes it easier for administrators to deliver personalized dashboards while maintaining centralized control.

• Row-Level Security is especially beneficial in industries that require strict data segregation, such as healthcare (showing patient data per doctor), finance (accounts per relationship manager), and sales (territory-based data per sales rep). It can be implemented in both Self-Service Analytics and Embedded Analytics models, depending on your use case.

Row-Level Security Mechanisms in Self-Service Analytics

In Self Service BI, business users build and consume dashboards within the Bold BI portal. Bold BI offers several built-in methods to apply Row-Level Security in this environment.

User Filters at the Data Source Level

• User Filters are the most straightforward and commonly used Row-Level Security method. These filters apply directly within the data source configuration, enabling row-level visibility based on predefined fields such as email, user ID, or department. Administrators can map these fields to Bold BI users or groups, ensuring dynamic filtering during dashboard load.

• This method is highly efficient for dashboards that are shared widely across an organization. For example, a sales dashboard can be shared with all regional heads, and the same layout will display only the data related to the user’s region. It is easy to manage and suitable for environments with clearly defined access control fields.

• User filters are recommended when security needs are moderate and user roles or departments are stable. However, they offer limited flexibility when the filtering logic becomes more dynamic or needs multi-level conditions.

Isolation Code at the Site Level

• Isolation Code provides a site-wide Row-Level Security mechanism, where a filter condition is enforced across all dashboards on a site. This is configured by the admin using a specific field in the dataset (e.g., “tenant_id” or “organization_code”) and is especially useful in multi-tenant deployments.

• Unlike user filters, isolation codes apply globally. If a user belongs to a tenant with isolation code “1001”, every dashboard in that site will filter data where tenant_id = 1001. This centralizes data filtering and minimizes dashboard-specific configurations.

• Isolation codes are ideal for scenarios where the same site is used by multiple external clients or departments, each needing strict data segregation. For example, in a SaaS analytics product, each customer company can access the same dashboards, and isolation code ensures data from one tenant is never visible to another.

Custom Attributes with Code View Mode

• Custom Attributes allow advanced Row-Level Security through query customization. Admins can define dynamic values per user, group, or site that can be substituted directly into SQL queries using custom attributes (e.g., @region, @user_id). This approach is powerful when more granular or conditional filtering is required.

• Custom attributes are versatile and can be used in conjunction with complex data models or role-based access rules. For instance, a manager could be assigned access to multiple regions via a comma-separated list, and a query can include a WHERE region IN (@region) condition to filter appropriately.

• This method is best suited for developers or power users who need to integrate business logic or custom access rules directly into their SQL or stored procedures. It provides high flexibility but requires a deeper understanding of query syntax and data modeling.

Row-Level Security in Embedded Analytics

• When Bold BI dashboards are embedded within external web or SaaS applications, Row-Level Security remains just as important. Users often authenticate through the host application, and dashboards are embedded using JavaScript SDK or iframe URLs.

• The recommended method for Row-Level Security in embedded analytics is through filter parameters passed during embedding. These parameters act similarly to user filters or isolation codes but are passed programmatically during dashboard load. For example, you can embed a dashboard and append a region filter like region = ‘South’, ensuring only relevant data is visible to the end user.

• This method gives developers full control over what each user sees, without storing sensitive filter logic in the frontend. It’s widely used in SaaS platforms where thousands of customers access the same dashboard template, and each must view only their data.

  • This is especially useful in customer-facing portals (e.g., billing dashboards, product usage metrics, user performance) where security and personalization are critical and where dashboards are part of a larger application ecosystem.

When to Use Which RLS Mechanism

Choosing the right method depends on your deployment type, dashboard usage, and user base.

• Use User Filters when your audience is internal, and the access rules are based on static mappings like department, user ID, or email. It’s quick and easy to implement.

• Use Isolation Codes in on-premises multi-tenant setups where a single site serves multiple clients or departments, and data isolation needs to be enforced across all dashboards.

• Use Custom Attributes when the filtering needs are dynamic or complex, and you want to apply logic at the SQL query level.

• Use Filter Parameters in Embedding when dashboards are consumed through third-party applications and need to reflect application-level user context.

Each of these can be used independently or in combination, depending on your project’s complexity.

Use Case Scenarios

• Regional Sales Reporting: A single dashboard tracks sales across the country. Sales reps see only their region using user filters; managers use custom attributes to view multiple regions.
• Client-Specific Dashboards in SaaS: A SaaS provider embeds a usage dashboard for all clients. Using embedding filters or isolation codes, each client views only their usage metrics without needing separate dashboards.
• Hospital Patient Monitoring: Doctors access a patient summary dashboard where they see only patients assigned to them. This is enforced using user filters tied to their user IDs.
• Education Platforms: In a school management system, dashboards display student performance. Teachers see only students in their class using custom attributes, while administrators see all.

Conclusion

Row-Level Security in Bold BI is a flexible and essential feature for delivering personalized, secure, and scalable analytics experiences. With multiple configuration options, organizations can choose the method that best fits their architecture, whether it’s internal BI usage or embedded analytics in customer-facing apps. By leveraging Row-Level Security effectively, teams can protect sensitive data, reduce development overhead, and provide consistent and meaningful insights to every user.

Additional References

• User Guide Documentation: Self Service Analytics
• User Guide Documentation: Embedded Analytics
• Knowledge Base Article: How to Implement Role-Based Access Control for Dashboards in Bold BI
• User Guide Documentation: Configuring Custom Attribute
• Blog: Row-Level Security with User-Based Filters
• User Guide Documentation: Configure Isolation code in site level