A shared application can serve many customer organisations efficiently. It must also maintain a reliable boundary between their records, actions and resources. That boundary is easy to describe in a sales conversation and surprisingly easy to weaken through a forgotten query filter, an export endpoint or a background job that loses customer context.
Multitenant design starts by defining what a tenant represents and how access to it is established. Data storage is part of that design, but isolation must continue through APIs, files, caches, search and support tools. The application should be able to explain why a particular user is allowed to perform a particular operation on a particular customer's information.
Define tenant membership separately from identity
A user account and a customer organisation are different concepts. One person may work for several organisations, and several people may belong to the same customer. Decide how memberships are granted, changed and removed, including the roles that apply within each organisation.
Choose how the active tenant is established for a request. A route, subdomain or selected organisation can indicate the requested context, but the server must verify that the authenticated user belongs to it. Treat a supplied tenant identifier as input to validate, not evidence of permission.
Include less obvious identities such as integration accounts, support staff and background workers. Their access needs explicit scope and ownership. An administrative convenience should not silently give every service the ability to act across the entire customer base.
Choose storage isolation from requirements
Common approaches include shared tables with tenant identifiers, separate databases and separate infrastructure for selected customers. Each changes the operating cost, isolation boundary and work involved in onboarding, upgrades and recovery. The choice should follow the actual customer and workload requirements.
Microsoft's guidance on multitenant storage and data compares isolation approaches and their trade-offs. No single layout removes the need for correct application authorisation, even when customers have separate databases.
Consider operational tasks when comparing options. Can the team restore one tenant, export its information or move it to another configuration? A design that makes initial onboarding easy but makes every customer-specific recovery difficult may create a substantial support burden later.
Enforce ownership when accessing records
Check both the requested action and the record's tenant ownership. A user who may view orders within one organisation should not gain access to another organisation's order by changing an identifier in the URL. Apply the same rule to updates, attachments and indirect references within a request.
Centralise common enforcement where that reduces omission, but understand where those mechanisms can be bypassed. Raw database queries, special reporting paths and administrative tools may not use the same filters as ordinary application screens. Review those exceptions explicitly.
For a hypothetical scheduling platform, a technician might be allowed to update assigned jobs within their tenant. The server must check tenant membership, job ownership and assignment rules. Hiding another tenant's jobs from the navigation does not protect the underlying endpoint.
Carry tenant context through asynchronous work
A background job needs an explicit, validated tenant context. Do not assume the web request's session will still exist when the job runs later. Record the relevant identity or authorisation context according to the task, and decide which permissions must be checked again at execution time.
Think about changes during the delay. A user may lose access after requesting an export, or a customer account may be suspended before a queued operation begins. Define whether the work remains authorised and how the system reports that decision.
Keep job status and results isolated as well. A carefully scoped database query is insufficient if the generated export is placed at a publicly accessible address. The route from request to stored result must preserve the same boundary throughout the workflow.
Include caches, search and files in the model
Use tenant-aware cache keys and validate the context of cached values. A key based only on a record number may collide across organisations. Shared caches need an explicit design for tenant scope, user-specific data and invalidation when access changes.
Apply appropriate access controls to document storage and search results. A search index can expose information even when the primary application's database queries are correct. Check that snippets, suggestions and generated summaries do not reveal material outside the user's permitted scope.
Review logs and support tools for similar problems. Operational records may include customer identifiers or document details, so access to them should match their purpose. An internal dashboard should not become an uncontrolled alternative route into customer information.
Test the boundaries with more than one tenant
Create test cases with at least two tenants and users with different memberships. Reuse similar record identifiers where the storage model permits it so tests do not accidentally rely on globally unique values to hide a missing boundary. Exercise reads, writes, exports and background results.
Test revoked membership, changed roles and attempts to mix references from different tenants in one request. A form can contain an authorised order identifier and an unauthorised attachment identifier; validating only the main record leaves a gap.
Include non-interactive clients and operational functions. Integration endpoints, reporting jobs and support impersonation features often have different code paths from ordinary browser use. Keep a small set of meaningful tenant-isolation checks in the delivery process so future changes do not rely only on manual review.
Manage resource sharing as well as confidentiality
One customer can affect another without seeing its data. A large export, heavy search workload or repeated integration failure can consume shared capacity. Establish quotas, concurrency limits and workload separation where the business needs predictable service.
Measure demand by tenant using appropriate operational identifiers. This helps identify concentrated load and informs decisions about dedicated capacity. Do not assume every large customer needs separate infrastructure; use observed behaviour and contractual requirements to justify the operating cost.
Worktechlabs can help design customer portals and .NET applications with clear tenant boundaries and verifiable access rules. Pair that work with permissions planning and cache design so isolation remains a property of the whole application as it grows.
