多租户切换需要同时改变工作区、权限和页面数据，还要处理原工作区未提交的内容。设计时先确定切换影响当前标签页还是所有标签页，再约定编辑中的表单怎样离开、旧详情链接怎样打开。只有目标工作区的身份与数据就绪，页面才能进入新的可操作状态。
可以先在后台原型中演示工作区切换，用两个权限不同的企业检查完整路径。本文使用虚构的设备服务后台：同一账号在“启明设备 A”拥有管理员权限，在“远山服务 B”只有查看权限；用户正在编辑 A 的工单备注，却需要去 B 查另一张工单。
让当前工作区成为持续可见的页面信息
同一账号能够进入两个企业，并不意味着两个企业拥有相同权限。Microsoft 的多租户身份设计说明指出，用户可以在一个租户具有管理权限、在另一个租户仅有有限访问权，并需要清晰的租户切换机制。页面设计应把这种差异表达出来，不能只替换左上角的企业头像。
在本例中，工作区名称持续显示在顶部；展开列表后，列出用户可访问的企业，并明确当前项。名称相近时增加能区分的企业简称或组织编号，不仅靠颜色。角色可以在列表或进入后的提示中显示，例如“远山服务 B · 只读”，但应以实际获取的权限为准。
切换入口附近不需要解释多租户数据库结构。用户真正关心的是“我现在在哪家公司、切过去能做什么、手头内容会怎样”。产品内部可用 tenantId 识别工作区，页面显示稳定的企业名称；改名不应导致草稿、链接或历史记录失去归属。
先决定切换后落在哪一页
从 A 的工单列表切到 B，可以进入 B 的工单列表，并采用 B 上次使用的有效筛选或默认筛选。从 A 的工单详情切到 B，则不应照搬当前工单编号：两边即使都存在编号 417，也不是同一业务对象。
| 切换前位置 | 本例切换后位置 | 处理理由 |
|---|---|---|
| A 的工单列表 | B 的工单列表 | 模块相同，数据与筛选归属重新确认 |
| A 的工单 417 详情 | B 的工单列表 | 详情对象不能跨企业直接对应 |
| A 的成员管理 | B 的可访问首页 | B 的只读角色没有成员管理入口 |
| A 的未提交表单 | 先处理离开选择，再进入 B | 表单内容仍属于 A |
筛选值也有作用域。“状态为待处理”可能在两边都成立，“负责人是 A 的某位员工”则不能直接带入 B。可以记住每个工作区自己的列表设置，但恢复前仍需判断字段、选项和权限是否有效；失效项清除后说明原因，不能让空列表看起来像 B 没有任何数据。
如果 B 没有同名模块或用户无权访问，进入一个确实可用的页面，并简短提示原因。不要把“功能未开通”“没有权限”和“没有记录”做成相同的空白页面，它们对应的下一步不同。
未提交内容先归属 A，再决定能否离开
用户在 A 的工单 417 中输入“到场前请联系值班人员”，尚未提交。这时选择 B，应先留在 A，说明“启明设备 A 的工单备注尚未保存”。弹窗上的动作要带着明确对象，避免只有“确定”和“取消”。
| 动作 | 后续行为 | 失败时 |
|---|---|---|
| 保存到 A 并切换 | 向 A 保存；确认成功后再开始进入 B | 仍留在 A，保留输入并显示保存失败原因 |
| 不保存并切换 | 按既定草稿策略处理本次编辑，再进入 B | 切换失败后如返回 A，明确当前是否还有可恢复内容 |
| 继续编辑 | 关闭离开提示，保持 A 的原页面 | 不触发切换或额外提交 |
“不保存”与“保留本地草稿”不是同一个承诺。如果产品支持草稿，应在动作说明中交代是否保留，以及重新进入 A 时在哪里恢复；如果会丢弃，也要清楚表达。草稿必须关联账号、工作区、业务对象和表单用途，不能只用“工单编辑草稿”作为全局名字。否则用户进入 B 后可能看到 A 的内容。
已经发起保存但结果未知时，不要立即切到 B 再说“保存成功”。先确认 A 的提交结果或按产品的后台任务策略提供明确去向；页面上的切换动作不能改变这次保存原本所属的企业。具体保存时机与恢复提示，可接入未保存提醒与草稿恢复的既有规则，不必为切换入口另造一套相互矛盾的逻辑。
过渡状态不能出现“B 的标题、A 的数据”
离开选择处理完之后，进入“正在切换至远山服务 B”的过渡状态，先停止原页面的新增操作。可以保留导航外壳，但应遮住或移除 A 的业务列表与详情，避免在 B 的工作区标识下继续显示 A 的客户名称。
待 B 的访问资格、菜单权限和目标页面数据都获得相应结果，再呈现可操作页面。若权限已确定但内容仍在加载，可以显示 B 的明确加载态；只有读取成功才显示列表或“暂无记录”。加载失败要提供重试，不能用空数据代替。
原先向 A 发出的搜索或详情请求可能在切换后才返回。交付说明中要要求这些响应与发起时的工作区、页面和请求轮次保持关联，过期响应不能写入 B 的视图。取消旧请求有助于减少无用工作，但仍需判断响应归属，因为请求不一定能够及时取消。
切换失败时，如果用户仍有 A 的访问权，可以恢复 A 的明确页面状态，并提示“未能进入远山服务 B”。如果 A 的访问权也已失效，则进入工作区选择或无权限页面，不能为了看起来恢复成功而继续展示旧业务内容。这里的界面约定帮助避免误操作，真正的数据隔离与授权仍要由服务端逐次检查，隐藏按钮不是权限控制本身。
详情链接携带归属，不随当前工作区重新解释
假设同事发来一个属于 A 的工单链接，用户此时正在看 B。链接应能确定它所属的工作区和对象，例如示意路径 /w/A/work-orders/417。页面不能取出 417，再到“当前工作区 B”中找同号工单。
处理链接时先核对用户是否有访问目标的资格。有权访问 A 的目标内容时，可提示将进入 A，再按照同一套未提交内容规则处理当前页面。如果在新标签页打开，则在新页明确显示 A 的归属。没有访问权时，只显示适当的无法访问说明和可用出口，不披露未经授权的企业名、工单标题或对象是否存在。
登录态过期后打开的深链接，也应在完成登录与授权核对后回到原目标，而不是只恢复一个不带工作区的对象编号。浏览器后退、书签和通知入口都可能带来旧上下文，应沿用这一判断，不能只保证顶栏下拉切换正确。
多标签页要选择一种清楚的上下文规则
本例采用“每个标签页保留自己的工作区”。用户在标签页一把 A 切到 B，不改变标签页二正在处理的 A 工单。每页都持续显示企业名称，标题也可包含简短企业标识，方便用户在两个标签间辨认。
这种设计适合同一人需要对照多家企业，但要求工程实现能够把请求、缓存和路由绑定到各自上下文，不能仅依靠一个随时被改写的全局“当前租户”。角色被移除或账号退出等全局事实，仍应按产品的会话策略影响相关页面；标签页独立不表示权限永远有效。
另一些产品采用所有标签页同步切换。若业务必须如此，旧标签页再次获得焦点时应明确提示“工作区已在其他页面更改”，阻止继续向旧视图提交，并让用户处理未提交内容后重新加载。不能在背景中把提交目标换成 B，却把 A 的表单完整留给用户。
两种方式都能设计，但必须在需求中写清。评审时让研发说明所采用的身份与会话机制是否支持所选规则，再决定交互；不要先画出互不影响的两个标签页，之后才发现系统只能全局切换。
把三个断点串成一条可评审的路径
在原型中准备 A 的编辑页、未保存提示、切换过渡态、B 的只读列表和外部详情链接入口。先输入 A 的备注，选择“保存到 A 并切换”，模拟一次保存失败，确认用户还在 A 且内容没消失；再让保存成功，进入 B，只展示 B 的数据与只读动作。
接着打开属于 A 的工单 417 链接，检查页面会回到 A 的目标对象，而不是寻找 B 的 417。最后并排打开两个标签页，在一个页面切换工作区，观察另一个页面是否按已约定的策略保持上下文或提示重新加载。再加入目标企业权限被撤销和旧请求晚返回两种情况，检查错误状态是否仍能说清当前归属。
交付结果可以是一张简短约定表：切换影响范围、离开确认动作、保存目标、落地页面、深链接归属、旧响应处理和权限失败出口。把这张表贴在对应页面旁，后续讨论就不必反复猜“切换”究竟包含哪些变化。需要将这些状态接入完整后台时，可继续参考原型交互专题中的页面流程方法。
