Circularo Multitenancy Guide
Introduction
This page serves as a short guide to facilitate the discovery process for the new organizations wishing to onboard into the Circularo eSigning System. The purpose of this page is to provide a clear understanding of the architecture logic involved in integrating new sub-entities into the system, along with some options for customization and configuration based on the specific needs of each organization.
It is essential for organizations to understand the possibilities and limitations of the system's customization options. More detailed documents aim to provide further clarity on how to utilize these options effectively to align the eSigning System with the unique requirements and preferences of each entity.
Glossary
Circularo Ultimate Multitenancy means that you can self-host Circularo Ultimate edition as a centralized single Circularo instance and share the same infrastructure and Circularo platform with multiple entities (“business tenants”). Depending on your configuration, these entities can share documents and users or be completely mutually independent.
In this document tenant refers also to Circularo “dedicated database” describing the particular multitenancy deployment and configuration options.
Technical analogy of dedicated databases can be Shared Schema and Shared Database vs. Individual Schema and Individual Database. Circularo dedicated database means Individual Schema and Individual Database.
Circularo Multitenancy supports both shared and individual schema / database configurations as part of the same deployment. And those approaches might be even combined. E.g There might be multiple Organizations configured using “shared schema/ database” but still be logically separated as business tenants or to be configured as “individual schema/database” dedicated databases.
Term | Explanation |
Entity | Logically connected group of users (i.e. company…). Specific type of Circularo user group with its own teams, users and documents completely separated from other such groups on the same instance. An entity must be a master entity or sub-entity. |
Master Entity | The one main parent entity which creates its subordinate sub-entities and manages their configurations. |
Sub-Entity | Child entity that has its configuration managed by its parent (master) entity. |
Team | User group owned by an organization which can be used to share documents and folders with multiple users at once. |
Dedicated Database | Circularo deployment configuration with data completely separated on the database level which behaves as a completely separate Circularo instance. |
Instance | Circularo instance is a single copy of the system running on a physical or virtual server in Docker containers. Usually there is Production, Dev and UAT Circularo Instance (environment). |
Multitenancy | A software architecture in which a single instance of software runs on a server and serves multiple tenants. It means having a number of tenants (organizations) all accessing a shared instance of the software, where they have the appearance that they are the only ones using it. Each tenant has their own data that only they can see and modify, so the context of a tenant establishes a data-access boundary. The term tenancy model refers to how tenants' stored data is organized:
|
Deployment Options
There are multiple deployment options we can use to achieve the multi entity setup. Each option might be more or less suitable for a particular deployment scenario as each option has different limitations, some more restrictive than others:
One Dedicated Database for One Organization with Multiple Teams
One Dedicated Database for Multiple Organizations and Teams
Multiple Dedicated Databases for Multiple Organizations and Teams (Multiple Tenants)
Option A - One Dedicated Database for One Organization with Multiple Teams
This deployment option consists of one organization, belonging to the master entity, which can then create and manage subsequent entities (sub-entities) under itself for each sub-entity it might need to create.
This option would mean that each entity has the same configuration as the master organization by default. Should there be a need for certain individual configurations for one or more of the sub-entities, it can be achieved by the use of the super administration.
The main advantage of this solution is that the basic user and team (entity) management can be done using the organization admin account (master entity admin), without the need to use the super administration, which should be reserved solely for the technical personnel use.
Schema for One Database with One Organization
One User Across Multiple Entities
While it is possible for one user to be a member of multiple entities in this configuration, this is somewhat limited by the fact that each user can only be a member of one group that shares its own custom settings (branding, SMTP settings, etc.).
This means that if the user is assigned to multiple entities, no more than one of these entities can have any sort of custom configuration and as such this configuration is more suitable for solutions where all subentities share the configuration of their master entity.
Option B - One Dedicated Database for Multiple Organizations and Teams
This deployment option consists of a single tenant, maintained by the master entity, on which there can be a number of organizations, one for each subentity (including the master).
This option would mean that by default, each new entity would have the default Circularo settings applied. These defaults can be changed by modifying the settings of the entire tenant using the super administration. Each organization can have a wide range of custom configurations done with the help of the super administration.
The main advantage of this solution is the independence of individual entities. Each entity will, from their point of view, have a separate Circularo environment with their own users, documents and teams, which are completely separate from other entities.
Schema for One Database for Multiple Organizations
One User Across Multiple Entities
This configuration does not allow for one user to be a member of multiple entities. The only way one person could access multiple organizations would be if they used two separate email ids (they can use email aliases), these would however be two separate user accounts with different configurations and documents.
Option C - Multiple Dedicated Databases for Multiple Organizations and Teams (Multiple Tenants)
This deployment option consists of multiple individual tenants running on the same hardware. Each entity needs to have a dedicated tenant. The tenant can only be set-up by a technical employee, which is a major drawback.
Each entity has completely separated data in its own elasticsearch indexes. While this might be beneficial in some cases (individual backup and restore, better customization options), it comes at a price of much higher hardware utilization, as elasticsearch can only run a limited maximum number of indexes on the same hardware.
The configuration of each entity is completely separated. Each entity will receive a completely blank non-configured option of the system upon deployment. There is no possibility to utilize configuration from another entity by default, or use a concept of a master entity and sub-entites. The configuration however can be imported from other tenants, but this is still a manual step.
Schema for Multiple Databases for Multiple Organizations
One User Across Multiple Entities
It is possible for one user to be a member of multiple entities, as the tenants act as 2 separate systems. The user will effectively have 2 different accounts that will not know about one another. It is possible to register under the same email in each tenant. The system will know under which account to authenticate the user by checking the URL the user is logging in from.
Frequently Asked Questions
General Multitenancy Questions
1. What is Circularo Ultimate Multitenancy, and how does it work?
Circularo Ultimate Multitenancy allows multiple organizations (business tenants) to share the same infrastructure while maintaining separate user groups, documents, and configurations. It supports both shared and individual schema/database configurations.
2. What are the key differences between the three multitenancy deployment options?
Option A - One Dedicated Database for One Organization with Multiple Teams: A single master entity manages multiple teams, sharing settings and administration.
Option B - One Dedicated Database for Multiple Organizations and Teams: Multiple independent organizations exist within a single tenant, each with its own users, documents, and settings.
Option C - Multiple Dedicated Databases for Multiple Organizations and Teams (Multiple Tenants): Fully independent tenants with separate databases and configurations, requiring technical setup.
3. Can Circularo support both shared and dedicated databases within the same deployment?
Yes, Circularo supports a mix of shared schema/database and individual schema/database configurations, allowing flexibility based on organizational needs.
User & Access Management
4. Can a user belong to multiple entities within the same Circularo instance?
This depends on the particular multitenant deployment configuration.
Option A: A user can be part of multiple teams but must share the same settings across all entities.
Option B: A user cannot belong to multiple entities under the same tenant unless they have separate email accounts.
Option C: A user can have multiple accounts across separate tenants but must log in separately for each.
5. Is it possible to use a single email address for multiple organizations or tenants?
Under Option B, users must use separate email IDs (or aliases) for each organization.
Under Option C, the same email can be registered in multiple tenants, but the login is determined by the URL used.
6. Who is responsible for managing user permissions and configurations?
In Option A, the master entity admin can manage user groups and teams.
In Option B, super administration is required to configure settings for each organization.
In Option C, each tenant is entirely separate, and configuration is handled at the tenant level.
Data & System Configuration
7. How is data stored and separated between different entities?
Option A & B: Data is logically separated within the same shared database but exists within the same physical infrastructure.
Option C: Data is completely independent, stored in separate logical databases for each tenant within the same physical infrastructure.
8. Can organizations customize their settings and workflows independently?
Option A: Sub-entities share the same configurations, with limited customization via super administration.
Option B: Each organization can have its own custom settings and workflows.
Option C: Each tenant has full configuration independence but starts from a blank system.
9. Can an entity migrate from one multitenancy option to another?
Yes, but with varying complexity.
Moving from Option A to B requires reconfiguring sub-entities as independent organizations.
Moving from Option B to C requires setting up a separate tenant and migrating data.
Technical & Performance Considerations
10. Does each deployment option impact system performance differently?
Yes.
Option A & B are optimized for shared infrastructure, reducing hardware requirements.
Option C requires more resources since each tenant has separate indexes and databases.
11. How does data backup and restore work across different options?
Option A & B: Backups cover the entire tenant, and restoring individual organizations requires manual intervention.
Option C: Each tenant has independent backups, allowing selective recovery.
12. Which option is best suited for large enterprises or government entities with multiple subsidiaries?
If subsidiaries need some shared configurations → Option B (One Tenant with Multiple Organizations).
If subsidiaries require full independence and separate data → Option C (Multiple Tenants).