Managing Multi-Tenant Access in ClicData Using Teams, Roles, and Parameters

When creating multi-tenant analytics environments, it’s easy to underestimate the complexity involved—even with powerful platforms like ClicData that offer extensive flexibility. At first glance, analytics seems like it should be straightforward: build a dashboard, connect your data, and share it with the right users. But in multi-tenant setups, those “right users” can vary dramatically by organization, product, and team, each with specific data entitlements.

The challenges compound when you’re trying to scale a single platform for many customers while preserving strict data boundaries. Security becomes paramount—not only to protect sensitive information but also to ensure compliance with internal policies and external regulations. Add to that the need to offer a flexible user experience, where different users from the same tenant might need slightly different views of the same data, and you begin to see the technical and governance tightrope you must walk.

This blog post outlines the practical steps taken to design a clean, maintainable, and secure access model for dashboards within ClicData. Whether you’re a small team building out your first client-facing reporting suite or a growing SaaS firm managing dozens of tenants, the approach we describe can help ensure each user only sees the data they’re entitled to—without creating unnecessary complexity in your dashboard logic or user management setup.

The Challenge: Controlling Access Across Tenants and Products

When building dashboards for multiple tenants, one of the most immediate risks is accidental data leakage—where internal users can access data that wasn’t intended for them. This might occur if a filter is incorrectly applied, or if a dashboard is shared too broadly. For example, a marketing analyst at Tenant A might inadvertently see revenue data from Tenant B, simply because of a misconfigured access rule. Even if the data is relatively benign, such breaches erode client trust and may violate internal agreements or compliance policies. Avoiding these scenarios requires designing access with the assumption that mistakes can and will happen—then putting controls in place to catch them.

Another challenge is the operational overhead that comes from managing too many exceptions or ad hoc configurations. It’s tempting to take shortcuts early on—hardcoding tenant names into dashboards, duplicating data sources, or creating custom views for individual clients. But this kind of short-term optimization becomes a long-term liability. As tenants grow and change, maintaining dozens of one-off configurations quickly becomes unsustainable. Worse, these inconsistencies can lead to reporting errors or make onboarding new clients slower and more error-prone. That’s why it’s crucial to design a model that scales cleanly with minimal duplication, using centralized logic and parameterized filters wherever possible.

We faced three main requirements:

1. Client-level isolation – Each client must only see their own data.
2. Product-level filtering – Some clients use one product, others use several. Views should reflect what they’ve purchased.
3. Internal user flexibility – Our internal teams need the ability for cross-client views, but with potential limits to which clients depending on their need and products they support.

We didn’t want to create and manage disjointed processes for dashboard and data access for each client and product. That would quickly become unmanageable. We also wanted a process that leveraged existing capabilities instead of building a system requiring custom interfaces and introduced extra levels of configuration steps.

So, we turned to ClicData’s Teams feature along with User Roles to design a parameter-driven process to create a unified but dynamic approach.

A pre-requisite: Customer and Product Model

As part of our initial design, we developed a Customer and Product data model that would enforce which customers have which products.  Additionally, we designed addition Product Configuration tables to address unique configuration requirements per Product.  As new products are developed or new customers subscribe to our products, we set up those relationships within our Analytics Admin Model.  The identifiers for customer_id and product_id are then used in the next steps during configuration.

Step 1: Structuring Teams and Roles for Each Client and User Type

In ClicData, Teams are a way to group users and assign shared permissions. For our needs, we decided to split teams into two types:

• Customer Teams: One per client organization.
• Product Teams: To define each analytic product within our platform.

In addition, Roles are required for users to access features within the Account. As we determined what roles to establish, we determined that typical users would fall into three categories:

• Single Client Only – Users who should have access to only one Client Organization. Typically this would be end users of our clients, who have no need to access a broad set of features and should only ever see their own data.
• Multi-Client Viewer – Typically will be supporting multiple clients on 1 or more distinct products. This is reserved for our non-client, product support or delivery specialists.
• Administrator (System/Account or Other Admin/Developer/Editor) – Requires access to a broad range of features and to all product configurations and clients. This is an extremely limited set of users.

Step 2: Using Team Parameters to Drive the Process

Each team has access to a curated set of dashboards and data views for team products. But more importantly, each team has its own Team Parameters.

Each team is assigned key parameters like:

• Parameter name: team_type – value options are “customer” or “product”.
• Parameter name: default_customer_id – only defined for “customer” team types to define the specific customer_id value. Only one customer_id value is set per customer team.
• Parameter name: product_id – for customer team types, can be a comma separated list for which the customer is subscribed. For product team types, this will only reflect the specific product_id value for the product.

Step 3: Using the configuration to control access

Until this point, the configuration has a loose association with what data and products users can access. To use the data as-is would be difficult and hard to follow. To make the data consumable for our dashboards, we derive a control table that will be used to limit each user based on their product and client assignment. By querying the ClicData API to get User and Team details, we then processed the data using a custom data flow to produce a normalized table list of the users, products, and associated customers for each user.

With this in place, we now have a centralized table to query in to limit access to products or data within our analytics solutions.

Real-World Impact

This approach gave us major benefits:

✅ Scalability – Add a new client? Just create a team and assign the right parameters, then create and assign the new users.  With a focus on ease of use and consistency in setup steps, adding onto your product suite will become easier to plug in.

✅ Security – Reduces the risk of accidental data leakage between clients along with ability to audit who has access to what. All filters are parameter-driven and enforced at the query level, driven by a well thought out approach to our delivery model.

✅ Operational Setup Simplicity – By keeping a level of consistency with the platform security infrastructure, teams and roles continue to define what users see and what they can do instead of introducing other processes that might conflict with the team and role model.

✅ Speed – Time to onboard a new client is reduced dramatically. Most of the work is in the setup of new users and a new client team, not in creating new reports or thinking through how we’ll deliver our analytics. This model also accounts for adding new product offerings within the platform.

Tips If You’re Building Something Similar

1. Name Teams and Parameters Clearly – Use a naming convention like “client_XXX_team” or “internal_ops_east” to stay organized. Having standard naming convention makes it easier on the Admin during setup to ensure they are assigning users correctly.
2. Centralize Parameter Definitions – Track who has what in a separate admin dashboard to reduce mistakes. With the ability to query the Teams and Users, you can develop internal audit reports to confirm the setup.
3. Test Access Frequently – Build a QA checklist to validate what each role/team sees before going live. Having a system reduces the potential for error, but having additional controls in place is best practice. These steps should include an impersonation step to ensure that everything is working as intended.
4. Document the Model – Internal documentation helps ensure future admins understand how the system is wired.

Final Thought

Using Teams, Roles, and Parameters within ClicData isn’t just a technical implementation, it’s a strategic architecture decision. It empowers you to grow without recreating the wheel every time a new client or product comes onboard.

If you’re building a multi-tenant SaaS or client-facing analytics solution, lean into these options early and leverage the tools provided. They’ll save you time, reduce errors, and help you scale with confidence.