Multi tenant SaaS testing should prove that each workspace can complete its allowed work and that the same actions fail when the actor, resource, or workspace is wrong. A happy-path browser test establishes usability for one account. Tenant isolation requires deliberate attempts to cross the boundary through every relevant access path.
Start with a small set of well-designed fixtures and a permission matrix. Add tests around customer outcomes and security boundaries rather than generating a large suite whose assertions simply mirror the implementation.
Build fixtures with distinct relationships
Create at least two isolated workspaces with clearly different records. Add an owner, an ordinary member, and a restricted role where the product supports one. Include a person who belongs to both workspaces with different permissions and a person whose membership has been removed.
Use synthetic identifiers and content that make accidental mixing easy to recognize. For example, a hypothetical maintenance platform could contain a North Depot workspace and a South Depot workspace, each with its own equipment and inspection records. Tests should know which records belong where.
Keep test data isolated between runs. Playwright's best practices recommend independent tests with isolated state and assertions focused on user-visible behavior. Apply that principle to database records and external side effects as well as browser cookies.
Write a compact permission matrix
List the important actions, roles, and ownership conditions. Creating an inspection, changing a member's role, downloading an export, and managing billing are different permissions. A single test named member permissions is too vague to explain what the suite protects.
For each allowed case, identify a corresponding denied case. A North Depot administrator may update a North Depot inspection. The same actor must not update South Depot's inspection by substituting its identifier. A read-only user must not gain write access by calling the endpoint directly.
Use the matrix to find missing boundaries. Search, counts, autocomplete, exports, and attachment links can reveal tenant data even when the main record page is protected. Include these secondary surfaces when they expose customer information or perform meaningful actions.
Test below the visible interface
Browser tests show that real workflows connect correctly. Service or API tests can cover permission combinations and invalid identifiers more efficiently. Focus each layer on a distinct question so the suite stays understandable.
A browser check might verify that a member cannot see the billing controls. A direct request must also verify that the server refuses the billing change. Then confirm the underlying subscription or entitlement record did not change. A hidden button and an HTTP error are insufficient if the operation still produced a side effect.
Scope resource lookup and modification to the authorized workspace in the actual application code. Tests should validate the outcome without being tied to a particular query function name. This allows a safe refactor while retaining the boundary the customer depends on.
Exercise changes during active sessions
Permissions are not static. A person may lose membership while a browser tab remains open. An owner can downgrade a role after an invitation was sent. A user may switch between two workspaces without reloading every part of the application.
Test these transitions explicitly. Remove the member, then attempt a read and a write from the existing session. Change a role, then retry an action previously allowed. Switch workspaces and confirm that cached records, selected objects, and newly submitted operations reflect the authorized current context.
In the maintenance example, a contractor might be removed from North Depot while still viewing an inspection. The next save must fail safely and explain that access changed. It must not silently save the inspection into whichever workspace the browser now considers active.
Follow tenant context into background work
Jobs and exports often outlive the request that created them. Test that the stored job context identifies the intended workspace and resource. The worker should load the correct records even when another user switches their browser workspace or an unrelated job executes at the same time.
Decide which permissions must be rechecked at execution and delivery. For a sensitive export, access when the file is downloaded matters even if the request was authorized earlier. A scheduled workspace-owned report may use a different execution policy. Test the documented policy rather than assuming every job acts as an eternal user session.
Introduce repeated and delayed delivery in controlled integration tests. If an event is processed twice, it should not create duplicate business effects. If a job fails, its retry should preserve tenant context and produce a recoverable application state.
Include commercial state transitions
A workspace can be technically authorized for an action but lack the required plan entitlement. Test subscription changes independently from membership permissions. An administrator should not bypass a plan restriction simply because the role has broad workspace authority.
Cover the specific behaviors your product promises after a trial ends, a payment state changes, or a limit is reached. Existing records may remain readable while new creation is restricted. Ensure the UI and server apply the same policy and that a delayed provider event cannot assign access to the wrong workspace.
Avoid running the entire provider network through every local test. Use deterministic fixtures for routine policy checks and a smaller set of controlled integration checks for the provider contract. Label what each type of evidence proves.
Make failures easy to investigate
Preserve enough evidence to understand a failed case: actor role, workspace, target record, action, expected result, actual result, and relevant request or job identifier. Keep credentials and private content out of test reports and screenshots.
Run the important isolation checks before releases that touch permissions, queries, exports, billing, or workspace switching. Broader testing should answer a concrete remaining risk. Agentium Start labels its automated test suite as partial in the feature catalog. Extend the supplied coverage around your own domain workflows and use verified boundaries as the release standard.
Authority References & Sources: