multi-tenant

Multi-tenant commonly refers to a software or system architecture in which a single deployed application instance and its underlying infrastructure serve multiple independent customers (“tenants”), while keeping each tenant’s data and configurations logically separated.

Core characteristics

In a multi-tenant architecture:

• Shared application and infrastructure: All tenants use the same running application codebase and typically share compute, storage, and network resources.
• Logical separation of data: Each tenant’s data is isolated through database schemas, row-level access controls, or equivalent mechanisms, even though it may be stored in the same physical database or cluster.
• Tenant-aware configuration: Settings such as branding, workflows, integration endpoints, and access rules can vary by tenant while still using the same core software.
• Centralized operations: Patching, monitoring, backups, and capacity management are handled centrally for all tenants.

Multi-tenant architectures are common in SaaS platforms that support many client organizations, such as supplier collaboration portals, MES-related cloud services, or quality and document management tools offered as shared services.

What it includes and excludes

Multi-tenant typically includes:

• Cloud or hosted systems where multiple customer organizations log into the same application environment.
• Platforms where access controls, role models, and namespaces are designed to distinguish and separate tenant data and workflows.
• Shared collaboration platforms where each manufacturer, supplier, or plant is treated as a tenant.

Multi-tenant typically does not include:

• Single-tenant deployments where each customer has its own dedicated application instance or environment.
• Simple multi-user systems within a single organization, unless the architecture explicitly treats organizational units as separate tenants.

Operational and compliance context

In regulated manufacturing and industrial environments, multi-tenant platforms intersect with topics such as:

• Access control and segregation of duties: Ensuring that users from one tenant (for example, a supplier) cannot view or modify another tenant’s data (for example, another supplier or customer site).
• Data residency and ownership: Clarifying where data is stored and who can access it within a shared infrastructure.
• Validation and change management: A change to a shared, multi-tenant system can affect many customers simultaneously, which influences validation strategies and release processes.
• Information security management: Standards such as ISO 27001 are often applied at the level of the multi-tenant service provider’s information security management system, not as a guarantee of security for a specific tenant.

Common confusion

• Multi-tenant vs single-tenant: In single-tenant setups, each customer has a dedicated instance of the application or environment. In multi-tenant setups, many customers share the same instance. Some vendors offer hybrid models (for example, logically separate databases but shared application layer).
• Multi-tenant vs multi-user: Multi-user simply means more than one user can access a system. Multi-tenant implies multiple distinct organizations or groups are intentionally separated within a shared system.
• Multi-tenant vs multi-site: In manufacturing, multi-site often refers to different plants or locations within one company. These may be modeled as separate tenants in some platforms, but not always; the term multi-tenant is architectural, not organizational.

Link to shared supplier collaboration platforms

For shared supplier collaboration platforms, multi-tenant usually means that one cloud-based application environment serves many customer organizations and their suppliers. Each organization is treated as a separate tenant, with its own users, permissions, data spaces, and integration endpoints, while all tenants rely on the same underlying application, security controls, and infrastructure managed by the provider.