How to Test Team Invites, Roles, and Workspace Access

Your app began with one user and one workspace. Now it supports invitations, editors, viewers, and customers who belong to several organizations.

The owner account still works. That gives you very little evidence about the new boundaries.

Permissions testing needs both successful and denied actions. The question is whether the right person can perform the intended action on the intended resource, and whether another person is prevented from doing it.

The examples below use fictional Owner, Editor, and Viewer roles. Treat their permissions as an example policy you should replace with your own.

Define a permission matrix

Write the policy before preparing accounts. Include sensitive reads as well as writes.

Also define special rules: the last owner may need protection, an invite may expire, and a removed member may retain access to a different workspace. These are decisions that a generic “check permissions” instruction leaves ambiguous.

The OWASP Authorization Cheat Sheet recommends checking authorization on each request. An interface that hides a button does not establish that the server rejects the operation.

Prepare separate identities and recognizable data

Create controlled test accounts for the roles you support. Use separate browser sessions so one account’s login state does not accidentally satisfy another account’s test.

Prepare workspace A and workspace B with clearly different project names. Give one account different roles across the two workspaces, and keep another account completely outside A.

For example, the same user can be an Editor in A and a Viewer in B. That setup detects a bug where the application carries an elevated role across a workspace switch.

Keep mailbox access available for the invite tests. Sending an invite and accepting it are separate observations; the members screen showing “pending” cannot prove delivery or successful acceptance.

Follow an invitation through acceptance

As the owner of workspace A, invite a controlled recipient with the intended role. Verify the pending invitation and open the delivered invitation in the recipient’s separate browser session.

Check the workspace name and role before accepting. After acceptance, verify that the recipient can reach the intended workspace and perform an allowed action. Then attempt an action their role should not permit.

Repeat relevant variations according to your policy:

• The recipient already has an account.
• The recipient needs to create an account first.
• An invitation has expired or been revoked.
• An accepted invitation is opened again.
• An invitation is opened while signed in as a different person.

For the last case, define whether the product requires switching accounts or explicitly permits a different acceptance model. The test should enforce that reviewed policy rather than accepting whichever account ends up in the workspace.

Test a denied action at both layers

Use a Viewer account. Confirm that editing is unavailable or appropriately explained in the interface. Open a bookmarked edit page and verify that it does not reveal restricted information or enable the operation.

Separately, in your own isolated test environment, run an integration check that submits the equivalent forbidden write. Assert that the server rejects it and that the original record remains unchanged. Include a forbidden read of a known resource in workspace A from the outside account.

Use controlled fixture resources and accounts for these checks. Record the account, workspace, resource, and action for each denial; a generic error page without that context is hard to interpret.

A small browser suite can protect the visible role experience. Server authorization tests should cover the underlying endpoints and resource boundaries more broadly.

Switch workspaces and verify context

With the account that has different roles, open a project in A, switch to B, and inspect the project list and available actions. Verify that A’s data does not remain visible as if it belongs to B.

Open a saved project link from A while B is selected. Your app might explicitly switch context, ask for a switch, or reject the navigation. Write down the intended behavior and check it consistently.

Use a create or edit action in the selected workspace and confirm the result belongs there after reloading. A correct-looking workspace label can coexist with a request scoped to the wrong organization.

Change or revoke access during an active session

Keep the Editor signed in while the owner changes that user to Viewer. Attempt a new edit from the existing session and verify that the server enforces the current policy.

Repeat after membership removal. A fresh request for a protected resource should be denied according to the revocation policy. Previously rendered pixels may remain in an open tab, so distinguish what was already loaded from what the server returns after access changes.

Finally, verify that removing membership in A does not remove legitimate membership in B. That negative side effect is easy to miss if the test only checks that A became inaccessible.

Keep permission coverage reviewable

Use this record for each important matrix cell:

Account and role:
Workspace and controlled resource:
Attempted read or write:
Expected allow or deny:
Observed interface result:
Server result and persisted state, where checked:
Environment, version, and evidence:

In HiTest, configure separate test accounts with clear workspace context. Write individual browser cases for important allowed and denied journeys; retain direct server checks in your integration suite.

When a new role or endpoint appears, update the matrix and coverage together. For the related question of whether a successful write reached the right place, continue with testing saved data.