How to Build Multi-Tenant Environments with Yellowfin BI

Multi-tenancy is almost a prerequisite to provide a secure environment for each of your customers when using business intelligence (BI) tools embedded in external services.

Although it is possible to control the access rights by granting individual access to user accounts without separating tenants, it is obvious that the management will become more complicated as the number of customers grows.

In a previous blog, we covered what multi-tenancy means in the context of embedded analytics. In this article, we will explain Yellowfin's multi-tenant feature specifically, and how it is built from the ground up to help you build external services with embedded BI. 

What is Yellowfin multi-tenancy?

Multi-tenancy is the ability to create multiple virtual instances within a single instance. For external services, it is common to create a virtual instance (tenant) for each customer and provide the service. In Yellowfin, multi-tenancy is realized by using the client organization. 

Read More: What is Multi-Tenancy? Understanding Multi-Tenant Analytics Deployments

What is a client organization?

A client organization consists of two levels: a parent level, the default organization, and a child level, the client organization. 

In the default organization, you can create reports and dashboards, as well as change system settings for the entire instance and manage client organizations, so it is the organization that manages all client organizations in the instance.

Client organizations can also create reports and dashboards. Security is often a concern as a disadvantage of multi-tenancy, but since each client organization is independent as a tenant, users within a tenant cannot see the data and contents of other tenants. 

Learn More: Client Organizations in Yellowfin BI - Multi-Tenant Analytics Deployment

Security Features of Client Organizations 

A slightly different security feature is in place for content created in the default organization, which can be viewed by all client organizations (but not edited, so that the content can be provided securely). This allows service providers to simply create and maintain content in the default organization, and provide all clients with up-to-date content at the same time. 

The concern here is data security. Yellowfin ensures data security by using a ‘client source substitution’ or ‘client reference ID’.

Security with Client Source Substitution

When building analytic services for external use, client data is often stored in separate databases for each client for reasons of service design and security. And if the database is physically separated for each customer, the risk of data leakage, such as mixing up data from other customers, is greatly reduced. 

Yellowfin client source substitution allows replacing only the data source of content created by the default organization with the customer's database. The service provider creates and maintains content by connecting to the data source defined in the default organization, but when customers view that content, they see data in their own databases.

Many Yellowfin BI customers take advantage of our high-security guarantees (underlying data in separate databases while still being on the same server) when leveraging our multi-tenancy feature-set to build centralized reporting solutions. One such customer was DataGrowers, who created new tenants for each of their clients to develop and share reports with ease, while ensuring their clients could only access their own data.

Case Study: DataGrowers builds embedded analytics for modern growers with Yellowfin

Security with Client Reference ID

Depending on the nature of the services you provide, there may be cases where all customer data is stored in a single database. In such cases, you can use the Yellowfin client reference ID feature. Even though all client data is stored in one database, it should be assigned an identifier to identify the client, and this identifier is used to narrow down the data and display it so that the client's data is not shown to other clients. 

In Yellowfin, when creating a client organization, an identifier called a client reference ID is set. For example, there will be data as shown in the figure below, and if you want to prepare a tenant for each client, you can register the client code as the client reference ID to force the data to be narrowed down and displayed by the client code.

Customizability for client organizations 

You do not want the UI of the service to be spoiled by embedding a BI tool. For example, if cool and sharp content is embedded into a service designed with a natural and soft image, the embedded part will float away, resulting in an uncomfortable UI. 

Yellowfin's design can be customized using images and style sheets, so by customizing it to match the design of the service to which it is being integrated, a sense of unity can be created when it is integrated into the service.

In other cases, you may want to customize the design to suit your clients. 

With Yellowfin, you can customize the screen style, chart colors, etc. for each client organization, so you can provide each client with a design that reflects their own brand colors. From the service user's point of view, it feels a little more special when the design is customized to a shade close to the company's brand image.

Read More: Multi-Tenancy, and Customized Content Management

Conclusion

Yellowfin includes a multi-tenancy with the security features and high customizability required for integration into external-facing services. In addition, the default organization, which allows centralized management of content for all tenants (customers), provides a mechanism to reduce management costs for service providers even when the service grows and the number of tenants increases.