Multitenancy
As a CCaaS provider (Partner), you can set up multiple virtually independent tenants provisioned from the same underlying infrastructure. Each tenant operates as a complete, independent contact center environment without dedicated hardware, possessing its own configurations, agents, teams, customers, and interactions.
Key Features and Benefit
Following is the multitenancy architecture
Expertflow CX multi-tenant design ensures tenants remain separate through logical partitioning: It provides following operational and economic benefits to both CCaaS provider (Partner) and the customer (tenant).
Benefits  | Partner (CCaaS provider) Benefit  | Business Value to Customer (tenant)  | 
|---|---|---|
Shared Resource Pool  | Cost Efficiency: Reduces hardware, maintenance, and software licensing costs by sharing infrastructure across all tenants.  | Lower, subscription-based pricing model, making advanced CX features accessible.  | 
Centralized Codebase  | Simplified Maintenance: A single, central application instance means you only update and patch once.  | Customers immediately benefit from new features and security fixes with zero downtime.  | 
Logical Data Isolation  | Security and Compliance: Data, configurations, and user settings for each tenant are logically segregated and invisible to others.  | Each tenant maintains its own set of business rules, agent skills, queues, and AI settings. Guarantees data privacy and compliance confidence (e.g., GDPR, HIPAA) even in a shared environment.  | 
Rapid Provisioning  | Accelerated Time-to-Market: Automated tenant onboarding allows you to set up new customers quickly and efficiently.  | New contact center environments can be activated in hours, not weeks.  | 
Tenant-Level Customization  | High Flexibility: Each tenant can independently configure their routing rules, queues, user roles, and branding without affecting other tenants.  | Customers get a tailored CX solution that meets their unique business processes.  | 
Reporting  | Reporting data is logically isolated, ensuring Tenant A cannot access performance metrics or conversation transcripts belonging to Tenant B.  | 
For new tenant provisioning, see this guide Tenant Onboarding - 5.0
Deployment Flexibility
The platform provides following deployment models.
Deployment Model  | Use Case  | 
|---|---|
Partner Private Cloud / On-Premise  | Allows the partner to host the single multi-tenant instance entirely within their environment  | 
Expertflow Cloud (Managed CCaaS)  | Partners can leverage the existing Expertflow managed instance to quickly co-brand and resell CCaaS, minimizing their operational overhead.  | 
Key Considerations
While multi-tenancy offers immense value for CCaaS, partners should be aware of standard considerations inherent to this architecture:
"Noisy Neighbor" Effect: Because resources (CPU, memory, database capacity) are shared, a sudden, heavy load spike from one very large tenant could, in rare cases, impact the performance of other tenants. Mitigation is achieved through sophisticated resource management and load balancing.
Customization Depth: While tenant-level customization (branding, routing logic, field names) is extensive, deep, core code modifications specific to a single customer are not possible, as this would break the shared codebase for all other tenants.
Dependency on the Provider: All tenants rely on the provider (or the partner hosting the solution) for maintenance, security patches, and platform uptime. A global issue with the shared platform affects all tenants simultaneously.
Complex Migration: Migrating a single tenant from the shared multi-tenant environment to a dedicated, single-tenant environment can be more complex than migrating a traditional, isolated application.
🚫 Limitations
For each tenant, a sub domain needs to be created before registering tenant in DNS records. For example, for tenant1 (tenant1.expertflow.com, tenant1.vrs.expertflow.com)
Some platform components are still not multitenant capable. A new instance of each of the following components must be provisioned for each of the following:
Conversation Studio
Control Flow
Outbound Flow
IVR Flow?
Reporting Connector - required for each tenant. See deployment guide for a each new tenant
Rasa is not part of the solution and an instance is required for each tenant. This will support multi-tenancy in the future.
Update Data platform Configmap upon each new tenant provisioning
Configurations such as WRAP_UP (enabled/disabled) or ThirdParty (enabled/disabled) are currently defined as core-level common settings, which means they apply globally across all tenants.
For historical database, only MySQL is supported and tested in a multi-tenant environment,
Not Available
Voicebot, Transcription, Translation are not available
Multiple deployments per tenant for the components which are not multi-tenant aware yet
Apisix authentication is not available in multitenancy but available on prem
Integration with Cisco is available for a single tenant only,
                                    