A B2B product can start with one application and a few customer accounts, yet still face an architectural decision early: what exactly must remain separate when those customers share the service? The answer affects much more than the database. It shapes onboarding, permissions, releases, support and the promises made during a sale.

This guide connects those decisions through a hypothetical workflow product. Its purpose is to help a team choose a defensible starting architecture and identify what would justify changing it.

Separate the service model from the hosting topology

The foundational NIST definition of cloud computing describes SaaS as customers using a provider's application on cloud infrastructure while the provider manages the underlying infrastructure. It also distinguishes service models from deployment models. These are different dimensions of a product.

A subscription describes a commercial arrangement. A dedicated deployment describes where a workload runs. Neither label, by itself, explains who operates the application, applies updates, recovers data or responds to incidents.

For a customer-hosted offering, write those responsibilities down. If the customer operates the software and infrastructure, describe that arrangement explicitly rather than assuming the subscription makes it SaaS. A provider-operated private deployment has a different responsibility model. The useful architectural input is the actual division of work.

Define a tenant before designing its database

In B2B software, a tenant often represents a customer organization, but that mapping is not automatic. One customer may need separate tenants for independent business units, regions or test environments. A tenant can contain many users. Microsoft's tenancy-model guidance also distinguishes the logical tenant from the deployment serving it.

In our hypothetical workflow product, a customer has two business units with separate administrators and document collections. The team should decide whether these are two tenants or two workspaces inside one tenant. That decision should follow the required boundaries, not the convenience of the first database table.

Record the meaning of customer, tenant, workspace and user in the product model. Then record how a tenant maps to infrastructure. Keeping these concepts distinct gives the team a clearer basis for discussing future relocation or dedicated hosting.

Treat isolation as an architectural requirement

A successful login establishes an identity; it does not establish that every subsequent operation is confined to the correct tenant. AWS's tenant-isolation guidance makes this distinction explicit. Isolation can use dedicated resources or policies on shared resources, and it needs consistent enforcement rather than relying on every developer to remember a filter.

For the example product, define the boundary in terms of observable behaviour: a user in one tenant cannot read, change, export or discover another tenant's documents. Apply that requirement when reviewing ordinary screens and less visible paths such as search, background processing and support tools.

Dedicated databases can contribute to isolation, but the team must still examine routing and access to those databases. The architecture decision is incomplete until it explains how the boundary is enforced and tested.

Map every operation to an authorized tenant

Tenant identification and authorization are separate steps. A subdomain, URL parameter or request header can help identify the intended tenant, but it does not prove the caller may access that tenant. Microsoft's request-mapping guidance explains this distinction and describes mapping through request properties or identity claims.

For our product, an employee who belongs to two tenants must select an active context. The server validates that context against the employee's access before processing a document. A background export needs an equally explicit tenant and authorized scope; it should not depend on whichever browser session happened to start it.

If the product later introduces AI-assisted actions, apply the same boundaries to their tools. Human approval of a proposed action and permission to execute it remain distinct decisions. Approval should not become a route around the tenant boundary.

Choose data isolation around operational requirements

Compare storage approaches using concrete requirements: workload, recovery, residency, customization and the team's ability to manage the resulting estate. Microsoft's multitenant storage guidance describes several combinations rather than one universal choice.

  • Shared database: tenants share a data resource, with tenant separation enforced through the chosen application and database controls. Capacity and recovery procedures must account for that shared boundary.
  • Dedicated databases: individual data stores can support more granular tenant operations, while provisioning, monitoring and schema changes must work across a fleet.
  • Mixed model: tenants or groups can use different resource arrangements when their requirements justify the additional operational complexity.

Test the recovery process before making a promise about restoring one tenant. With shared storage, recovery may require a separate restored copy and selective extraction. A dedicated database still needs a tested procedure and consideration of dependencies outside that database.

For our example, “separate customer data” is too vague to decide between these options. “Restore one customer's document collection without reverting another customer's work” is a requirement the team can evaluate.

Make the deployment unit repeatable

A tenant does not have to equal one application instance. The Deployment Stamps pattern groups application components and data stores into repeatable units. A unit can serve one tenant or a group, and different units can serve different regions or release groups.

This creates a way to discuss growth beyond “make the server bigger.” The team can establish the tested capacity of a unit and a process for placing tenants into another one. However, multiple units also introduce routing, monitoring and configuration work. A stamp is not automatically a disaster-recovery solution or a reason to duplicate everything immediately.

For an early product, document the deployment boundary and reproduce it in a controlled environment. Add production units when capacity, geography, isolation or release requirements justify them. Preserve the option through repeatability, rather than building an unsupported fleet in advance.

Give tenant lifecycle operations an owner

The customer-facing application is only part of the service. Someone must create tenants, apply configuration, provision resources and eventually offboard them. Microsoft's control-plane guidance separates these management responsibilities from the data plane through which customers use the application.

A small product may begin with a tenant registry and documented, reusable operational scripts. A comprehensive administrative platform is not a prerequisite for every launch. What matters initially is that the team knows the intended state of each tenant and can explain how an operation reaches that state.

For our workflow product, record whether onboarding is requested, provisioning, ready or awaiting intervention. Decide who may perform each transition and what evidence confirms completion. Those are proposed product requirements for this example, not a prescribed universal lifecycle.

Keep deployment variants within a common release process

A dedicated customer should not silently become a separate product branch. Microsoft's deployment and configuration guidance recommends repeatable deployment and warns about tenant-specific customizations. It also distinguishes temporary rollout flags from entitlements that control purchased capabilities.

For the example, keep supported variation explicit: deployment location, approved integrations, configured limits and enabled capabilities. Apply changes through a documented release process, with compatibility checks for the environments the team actually supports.

If customer-hosted deployments are offered, add a responsibility agreement covering upgrades, monitoring access, backups and incident handling. Supporting one codebase does not remove differences in the customer's network or operating procedures. Treat those differences as support commitments to evaluate before selling the option.

Measure the service at the tenant boundary

A healthy fleet average can hide one customer's poor experience. Microsoft's multitenancy checklist calls for tenant-level health monitoring, consumption measurement, isolation tests and performance objectives aligned with customer requirements.

For the hypothetical product, choose an important journey such as submitting and retrieving a workflow document. Test it while another tenant runs a large export. Establish acceptable outcomes from the product's commitments, then inspect where contention appears. The response might involve capacity, scheduling or greater isolation; the experiment should inform that choice.

Include operational effort when comparing costs. A lower infrastructure bill is not a complete business case if the arrangement creates recurring manual work the team cannot sustain. Use measured workload and support evidence to revisit the design.

A practical starting decision

Suppose the workflow product begins with a small group of business customers in one region. None currently requires dedicated infrastructure, but each requires access separation and an agreed recovery process. A reasonable proposal to evaluate could include:

  • One documented tenant model and an explicit user-to-tenant membership model.
  • A shared application deployment with a data approach selected through isolation and recovery tests.
  • A tenant registry, repeatable provisioning and a common release pipeline.
  • Recorded criteria for introducing dedicated resources or another deployment unit.

This is a hypothetical starting point, not a recommendation for every SaaS product. A customer's requirements or a failed recovery test could change the decision before launch.

The useful architecture record explains what is shared, what is separated, who operates each part and which evidence would trigger a change. That gives product and engineering teams something concrete to build, test and discuss with customers.

Sources

Documentation checked on 31 October 2026. NIST SP 800-145 was published in 2011 and is used here as foundational terminology, not as a recent announcement.