Workspace switching: make the active organization unmistakable

Create two clearly different test workspaces

Use workspaces and accounts you control. Give each workspace recognizable synthetic records and, where appropriate, different permissions. Avoid real business data and production changes during exploratory checks.

Begin with a task that reads a record in one workspace, then switches to the other. Record the workspace label, page title, selected item and available actions before and after the switch.

In an illustrative review, a contributor might be allowed to create drafts in Workspace A but only read them in Workspace B. The interface should explain that difference rather than simply leaving a familiar button disabled without context.

Check the transition, including unfinished work

Inspect what happens if a draft is open when the switch begins. Does the product preserve, discard or ask about the work? Whatever the intended behavior, the consequence should be understandable before the person commits to the transition.

Next, use the browser's back navigation and reload the page. Check whether the active workspace remains coherent with the visible record. A saved link should also resolve within the product's intended context rather than making the person guess which organization it belongs to.

If the application supports multiple tabs, inspect a controlled example in which each tab has a different context. The goal is to understand the documented behavior, not to assume every product must synchronize tabs in the same way.

Inspect context at consequential moments

Look at the screen immediately before saving, inviting, submitting or exporting. Can the person identify the target organization at the moment the action matters?

Use a narrow checklist:

• The active workspace is identifiable.
• The visible records match that workspace.
• Permissions and unavailable actions are understandable.
• Switching does not silently misrepresent unfinished work.
• Returning through a link or reload produces coherent context.

Do not mistake a clean screen for tenant isolation

A walkthrough can expose stale labels, wrong destinations and confusing permissions. It cannot prove that the backend prevents cross-workspace reads and writes.

Report the two concerns separately: context clarity observed in the interface, and isolation established by authorized technical tests. If an unexpected record appears, stop the affected task and preserve minimal redacted evidence for investigation.

Clear workspace context gives people confidence about their next action. That confidence should rest on both understandable navigation and independently verified access controls.

Next step: Use the privacy-conscious testing guide when planning cross-workspace test fixtures and evidence.