Multi-tenancy can be treated as a line through a stack of layers: shared below, per customer above. Practice draws it high. Once the per-customer part is cheap to produce, the line can move down, so that onboarding, the interface and each customer's domain document vary per customer while the domain capability and the platform that runs it stay shared.
It helps to treat multi-tenancy as a line drawn through a stack of layers rather than as a property of a product. Everything above the line varies per customer. Everything below is shared. Vendor guidance already describes tenancy per layer: AWS notes that many systems run some components siloed per tenant and others pooled (Silo, Pool, and Bridge Models, AWS Well-Architected SaaS Lens), and Microsoft describes horizontal deployments that share some tiers and dedicate others to each tenant (Tenancy models for a multitenant solution, Azure Architecture Center, 2025).
Conventional placement. Practice pushes the line as high as it will go. The higher it sits, the more layers are shared, and the more of the original economy of scale is captured. The user interface is the same for every customer, and configuration is the mechanism that lets a shared stack behave differently for different customers without any shared layer being rewritten. Current guidance is explicit about keeping per-tenant variation out of the shared layers, advising against deploying "features or a configuration that only applies to a single tenant" (Architectural approaches for the deployment and configuration of multitenant solutions, Azure Architecture Center).
Two layers in the middle of the stack behave differently and are worth separating. The business rules say how each customer's policies, approvals and workflows apply the product's capabilities, and they vary from customer to customer. Beneath them sit the domain primitives: the entities, calculations and relationships every customer relies on. They change far less. Two payroll customers can have different overtime policies while sharing the same definition of a pay element. The product exposes these primitives through its APIs, which often cover a large part of the domain, though not always at the granularity a domain language needs.
Two consequences follow.
The first is that onboarding becomes the product's real surface. A customer cannot use the system until someone has mapped their requirements onto the available configuration. That mapping is where the domain knowledge concentrates, and it is usually the least formalised part of the whole operation. It also recurs for the life of the account. Requirements change, laws change, organisational structures change, and policies change, so the mapping has to be revisited each time.
The second is that anything the configuration mechanism did not anticipate becomes an engineering task. The product's flexibility has a boundary, drawn years earlier by someone estimating how much variation there would ever be, and crossing it requires work on layers that other customers are also running on. Section 1.1 describes what that work tends to leave behind when it is done under deadline.
Products do offer ways to stretch that boundary. Mature products let customers adjust business rules through configurable workflows. Salesforce describes most common automation scenarios as buildable in its flows (Flow Basics, Salesforce Trailhead), and Workday describes more than 850 preconfigured business processes that customers can change without IT support (The Workday business process framework, Workday datasheet). Where a customer needs data the model did not include, platforms offer custom fields and objects stored as metadata, so the shared schema itself does not change: the platform "does not create an actual table" (Platform Multitenant Architecture, Salesforce Architects), a technique studied as mapping tenant extensions onto shared tables (Aulbach et al., SIGMOD 2008). In our experience these extensions often hold information at the edge of the domain rather than at its core.
Customisation itself is close to universal. In Panorama Consulting's 2015 survey of 562 organisations implementing ERP, only 7% of organisations customised nothing, while 12% reported extreme or complete customisation (2015 ERP Report, Panorama Consulting). The survey covers ERP in general rather than SaaS, and does not say which layer each change reached. It is consistent with, though not evidence for, most variation sitting in the upper layers. In a multi-tenant product, the deeper a change reaches, the more customers it puts at risk.
Lowering the line addresses both. The illustration below shows one plausible placement once it has moved.
| Layer | Conventional placement | After the line moves |
|---|---|---|
| Onboarding | Per customer, as configuration values | Per customer, as a validated document |
| User experience | Shared | Per customer, generated or composed per tenant and per user |
| Business rules | Shared code, switched by configuration | Shared primitives, composed per customer in a domain document |
| Execution and data | Shared | Shared |
| Infrastructure | Shared | Shared |
The placement follows from section 1.3. What stays shared is the domain capability and the platform that executes it. What moves above the line is how that capability is presented and mapped for each customer.
It also answers the customisation question in section 1.3. A customer's variation lives in that customer's own domain document, composed from shared primitives and validated against the domain's rules. Meeting a new request then means adding to one customer's document, or, where the language cannot yet express it, attaching a plugin scoped to that customer until the need is understood well enough to become part of the language (section 15). Either way the shared layers stay untouched, which removes the mechanism by which section 1.1's special cases accumulate.
Lowering the line gives up some of the sharing that justified the original design. That is affordable only once producing the per-customer part has become cheap, which is the condition that has changed.