When implementing a multi-tenant reporting solution in Bold Reports, choosing an appropriate content organization strategy is just as important as designing the database architecture.

While tenant-specific data isolation can be achieved through Custom Attributes and dynamic database selection, report organization, permissions, and administration can be structured in multiple ways depending on your business requirements.

This article discusses the two most common approaches for organizing content in a multi-tenant environment:

1. One Site per Tenant
2. Single Master Site with Categories

For database-level tenant isolation, refer to:

Multi-Tenant Database Connectivity Using Custom Attributes

https://support.boldreports.com/kb/article/24854/multi-tenant-database-connectivity-using-custom-attributes

Understanding the Relationship Between Content Organization and Data Isolation

Content organization and data isolation address different aspects of a multi-tenant architecture.

Content Organization determines:

• How reports are organized.
• How permissions are applied.
• How tenant-specific content is managed.
• How administrators maintain reporting assets.

Data Isolation determines:

• Which database is used during report execution.
• Which tenant’s data is returned.
• How tenant-level security is enforced.

Regardless of the chosen content organization strategy, we recommend using Custom Attributes to dynamically determine the target database at runtime.

This enables:

• A single report definition across multiple tenants.
• A single data source definition across multiple tenants.
• Simplified report maintenance.
• Tenant-specific database connectivity.

User Management Considerations

The content organization model and user management model are independent architectural decisions.

In embedded reporting deployments, users do not necessarily need to be created within Bold Reports.

Application-Managed Users

Many SaaS and embedded applications manage authentication and authorization entirely within the host application.

Application Users
        │
        ▼
Application Authentication
        │
        ▼
Application Authorization
        │
        ▼
Embed Token
        │
        ▼
Bold Reports

In this model:

• Users are managed by the application.
• Authentication is handled by the application’s identity provider.
• Authorization is controlled by the application.
• Users do not need to exist within Bold Reports.
• Tenant information can be passed through Custom Attributes and embed tokens.

This is a common approach in embedded reporting solutions where Bold Reports is used primarily for report execution and rendering.

Bold Reports Managed Users

Users can also be created or imported into Bold Reports.

Identity Provider
        │
        ▼
Bold Reports Users & Groups
        │
        ▼
Permissions
        │
        ▼
Reports

In this model:

• Users and groups are maintained within Bold Reports.
• Permissions are managed through Bold Reports.
• Direct portal access can be provided.
• User and group attributes can be used for tenant-specific database selection.

Static Tenant Users

A hybrid approach commonly used in embedded deployments is to create a dedicated user for each tenant.

[email protected]
[email protected]
[email protected]

Custom Attribute values can be assigned to these users:

[email protected]
└── DatabaseName = Company1DB

[email protected]
└── DatabaseName = Company2DB

The application can then generate embed tokens using the appropriate tenant user, allowing reports to dynamically connect to the correct tenant database.

Recommendation

For most embedded multi-tenant deployments:

• Application users are optional within Bold Reports.
• Authentication and authorization remain within the application.
• Custom Attributes are used for database selection and tenant context.
• Static tenant users can be used when tenant-specific attribute management is required.

Option 1: One Site per Tenant

If each tenant should operate independently with complete separation of reports, permissions, schedules, and settings, you can create a dedicated site for each tenant.

Example Structure

Master Site
├── Common Reports
├── Shared Data Sources (Designed with Custom Attributes)
└── Attribute Values (Non-Production Data)

Site: Company1
├── Default Reports (Published from Master Site)
├── Tenant Specific Reports
├── [email protected]
│   └── User Specific Reports
├── [email protected]
│   └── User Specific Reports
├── Users (Application Users - Optional)
├── Data Sources (Published from Master Site)
└── Attribute Values (Company1 Production Database)

Site: Company2
├── Default Reports (Published from Master Site)
├── Tenant Specific Reports
├── [email protected]
│   └── User Specific Reports
├── [email protected]
│   └── User Specific Reports
├── Users (Application Users - Optional)
├── Data Sources (Published from Master Site)
└── Attribute Values (Company2 Production Database)

How It Works

• Common reports are maintained in the Master Site.
• Shared data sources are designed once using Custom Attributes.
• The Master Site can be configured with non-production attribute values for report design and testing.
• Reports and data sources are published from the Master Site to tenant sites.
• Each tenant site maintains its own production attribute values.
• The same report definition can connect to different tenant databases based on the site’s attribute values.
• Tenant-wide reports are maintained under Tenant Specific Reports.
• User-specific content can optionally be maintained under individual user categories.

Benefits

• Strong tenant isolation.
• Independent administration.
• Separate permissions and schedules.
• Separate report catalogs.
• Easy tenant-specific customization.
• Clear separation of content and configuration.

Considerations

• More sites must be maintained as the tenant count increases.
• Shared content requires a publishing strategy from the Master Site.
• Administrative overhead may be higher for large tenant counts.

Best Fit For

• Tenants require strong separation.
• Tenant administrators manage content independently.
• Scheduled jobs and configurations vary by tenant.
• Tenant-specific customization is common.

Option 2: Single Master Site with Categories

In this approach, all tenants are maintained within a single Bold Reports site.

Tenant separation is achieved using Categories and Subcategories.

Example Structure

Master Site
│
├── Company1 (Category)
│   ├── Tenant Specific Reports
│   ├── [email protected] (Category)
│   │   └── User Specific Reports
│   └── [email protected] (Category)
│       └── User Specific Reports
│
├── Company2 (Category)
│   ├── Tenant Specific Reports
│   ├── [email protected] (Category)
│   │   └── User Specific Reports
│   └── [email protected] (Category)
│       └── User Specific Reports
│
├── Common Reports
│
├── Attribute Values (Non-Production Data)
│
├── Users (Application Users - Optional)
│
└── Static Tenant Users
    ├── [email protected] (Attribute Values Assigned)
    └── [email protected] (Attribute Values Assigned)

How It Works

• All content is maintained within a single Master Site.
• Each tenant is represented by a Category.
• Reports shared across users within a tenant are stored under Tenant Specific Reports.
• Additional user categories can be created for user-specific reports.
• Application users are optional and can be managed entirely by the host application.
• Static tenant users can be used to store tenant-specific Custom Attribute values.
• Category-level permissions can be used when access control is managed within Bold Reports.

Benefits

• Centralized administration.
• Easier onboarding of new tenants.
• Single location for report management.
• Reduced maintenance overhead.
• Scales well for large tenant deployments.
• Simplified governance and deployment processes.

Considerations

• Requires a well-planned permission model.
• Large deployments may result in a significant number of categories.
• Tenant isolation is logical rather than site-based.

Best Fit For

• Embedded reporting is the primary use case.
• Authentication and authorization are managed by the application.
• A centralized administration model is preferred.
• A large number of tenants need to be supported.
• Most reports share a common design and structure.

Choosing the Right Approach

Recommendation

For most embedded SaaS applications, we recommend:

• Single Master Site with Categories for content organization.
• Custom Attributes for dynamic database selection.
• Application-managed authentication and authorization.
• Embed Tokens for passing tenant context.
• Optional static tenant users for storing tenant-specific attribute values.

For organizations that require stronger separation, independent administration, or tenant-specific customization, a One Site per Tenant architecture may be a better fit.

Regardless of the chosen organization model, combining Custom Attributes with a well-structured content hierarchy provides a scalable and maintainable multi-tenant reporting architecture while minimizing report and data source duplication.