Welcome to the FlowWright Multitenant Configuration User Guide.
This guide explains the configuration and use of FlowWright and its features in a multitenant environment.
FlowWright's multitenant architecture lets a single FlowWright application environment support multiple independent organizations, departments, or customers (tenants) while maintaining logical separation of their data, workflows, users, and configurations.
The primary objective is to allow organizations to share the same underlying FlowWright platform without interfering with one another's business processes.
In an enterprise BPM and workflow automation platform such as FlowWright, multitenancy is particularly useful for:
- Hosting multiple customer organizations on a shared infrastructure.
- Providing centralized administration of the FlowWright platform.
- Maintaining tenant-specific process definitions, forms, users, and security.
- Reducing infrastructure and maintenance costs.
- Supporting independent business operations within a common application environment.
1. Understanding the architecture shown in the image
The image below illustrates FlowWright's multitenant architecture. The central concept is the separation of the Tenant Manager from the individual tenant environments.
The multitenant SaaS architecture uses a separate database for each tenant. The application engines are designed to operate in a multitenant environment.
The architecture can be understood through the following components.
A. Tenant Manager
The Tenant Manager is the centralized administrative interface for managing the multitenant FlowWright environment.
It is responsible for activities such as:
- Creating and configuring tenants.
- Managing tenant-specific configuration.
- Maintaining the tenant database connection information.
- Enabling centralized administration of the tenant environments.
- Managing platform-level operations that affect multiple tenants.
The Tenant Manager is distinct from the regular tenant application.
For example, a platform administrator can manage several customer environments from the Tenant Manager without logging in separately to each customer's application.
B. Individual tenants
Each tenant represents an independent organization or business unit.
For example, a FlowWright SaaS deployment could have the following tenants:
Each tenant operates independently, even though they share the same FlowWright application infrastructure.
C. Separate tenant databases
One of the most important characteristics of FlowWright's multitenant architecture is its database isolation.
Each tenant has its own database.
This architecture reduces the risk of one tenant accessing another tenant's business data.
It also simplifies certain administrative operations, such as migrating a tenant's database or troubleshooting tenant-specific data issues.
2. How FlowWright processes a request in a multitenant environment
Consider a SaaS deployment where three organizations use FlowWright.
The request-processing sequence is as follows:
- A user accesses the FlowWright application or invokes a FlowWright API.
- The application determines the tenant associated with the authenticated user or request.
- The tenant configuration is resolved.
- The appropriate tenant database is selected.
- The FlowWright engine executes the requested operation using the tenant's data and configuration.
- The result is returned to the user.
Important: Enforce tenant identification and authorization. A user should not be able to access another tenant's database simply by changing a tenant identifier in a request.
3. Shared application infrastructure versus isolated tenant data
FlowWright's multitenant architecture balances resource sharing with data isolation.
The shared infrastructure improves operational efficiency, while tenant-specific databases provide a strong data-separation boundary.
However, sharing application infrastructure does not necessarily mean that every component is shared. FlowWright's implementation also distinguishes tenant-level operations from platform-level operations.
For example, its documentation explains that compiling a microservice DLL can trigger an application-domain reload, potentially affecting all tenants. The system therefore handles such operations through centralized administration rather than treating them as ordinary tenant-specific changes.
4. Tenant Manager versus Tenant Application
This distinction is particularly important for FlowWright administrators.
The Tenant Manager is for platform administrators, while the tenant application is for the organization's business users and administrators.
FlowWright's official installation guide describes selecting the Multi-Tenant Installation option and then accessing the Tenant Manager interface.
5. Benefits of FlowWright's multi-tenant architecture
Operational benefits
- Centralized administration: Manage multiple tenants from a common administrative interface.
- Reduced maintenance: Maintain a single FlowWright application instead of maintaining a separate application for each tenant.
- Scalability: Add tenants without necessarily deploying an entirely new application stack.
- Simplified upgrades: Apply application-level upgrades centrally, subject to compatibility and operational requirements.
Security benefits
- Database isolation: Each tenant has a separate database.
- Independent access control: Tenant users operate within their own authorized environment.
- Reduced data exposure: Tenant-specific databases help prevent accidental cross-tenant data access.
- Independent data management: Tenant databases can be managed and backed up separately.
These benefits are consistent with FlowWright's documented multitenant architecture.
6. Example: FlowWright as a SaaS platform
Imagine FlowWright is offered to three customers:
- A banking organization automates loan approvals.
- A manufacturing company automates purchase orders.
- A healthcare organization automates patient onboarding.
All three organizations use the same FlowWright application infrastructure.
However:
- The banking organization's loan approval workflow exists only in its tenant environment.
- The manufacturing organization stores its purchase order data in its own tenant database.
- The healthcare organization's process instances and business data are isolated from the other tenants.
A workflow failure in one tenant should not expose another tenant's data. At the same time, platform-level failures, shared resource exhaustion, or application-wide maintenance can still affect multiple tenants.
This is why multitenant architecture must address both tenant data isolation and shared infrastructure reliability.
Summary
FlowWright's multitenant architecture can be summarized as follows:
- A common FlowWright application infrastructure serves multiple tenants.
- The Tenant Manager provides centralized tenant administration.
- Each tenant has a separate database.
- Tenant-specific workflows, forms, configurations, and business data remain isolated.
- The FlowWright engines are designed to support multitenant execution.
- The platform manages operations separately from tenant-level business activities.
For FlowWright SaaS deployments, this architecture lets multiple organizations use a common workflow automation platform while keeping their business environments independent.