检查账户访问权限和登录方式
检查谁可以进入 Humind 公司，以及每个账户如何进行身份验证。本指南使工作专注于账户访问，并提供一条可重复执行的路径，新 Humind 用户无需更改无关配置即可遵循。 工作区访问将个人账户设置与公司角色和权限结合在一起。每位团队成员都应使用自己的账户，只获得履行其职责所需的访问权限，并保持登录详细信息为最新。安全审查是一种持续的运营习惯，而不是一次性的设置任务。 开始之前 访问权限： 个人登录详细信息仅对账户所有者可见。公司成...
检查谁可以进入 Humind 公司，以及每个账户如何进行身份验证。本指南使工作专注于账户访问，并提供一条可重复执行的路径，新 Humind 用户无需更改无关配置即可遵循。
工作区访问将个人账户设置与公司角色和权限结合在一起。每位团队成员都应使用自己的账户，只获得履行其职责所需的访问权限，并保持登录详细信息为最新。安全审查是一种持续的运营习惯，而不是一次性的设置任务。
开始之前
访问权限：个人登录详细信息仅对账户所有者可见。公司成员资格和角色需要团队或公司管理权限。
- 使用正确的 Humind 公司。
- 收集已批准的团队成员名单和角色负责人。
- 不要请求或分享任何人的密码。
在下文所述的最小负责区域内工作，并在准备更改时保持当前面向客户的状态可用。在点击任何最终操作之前，请确认 Humind 中显示的当前公司、Agent、商店、语言和市场。缺少某个控件可能表示只有只读访问权限，或表示该公司尚未配置某项功能。在这种情况下，请记录预期任务，并请管理员审查确切的权限或依赖项。不要通过共享账户、将数据复制到其他区域，或承诺工作区未提供的功能来绕过这一边界。
分步工作流程
确认范围和当前状态
先检查你自己的登录方式和恢复路径，然后如果你的角色允许公司管理，再打开团队访问设置。
- 编辑前确认当前公司和 Agent。
- 记录当前状态，以便在更改后比较结果。
- 如果屏幕或权限与预期任务不匹配，请停止操作。
准备更改
将活跃成员和待处理邀请与已批准名册进行比较，使用电子邮件和稳定身份，而不是仅依赖显示名称。
- 使用能够完成客户任务的最小更改。
- 将权威信息保留在其所属来源中。
- 保存前检查标签、日期、语言和客户可见措辞。
保存并等待所需处理完成
按照最小权限原则检查角色，并识别需要负责人决策的外部、非活跃或看似重复的访问权限。
- 等待界面确认更改已保存。
- 如果需要同步、索引或发布，请等待其最终状态。
- 重新加载该区域，并确认保存的值仍然保留。
测试完整的客户旅程
仅应用已批准的邀请、角色或移除更改，然后请受影响的团队成员通过其常用登录方式验证访问权限。
- 使用新的会话和真实的客户场景。
- 当结果显示在店面上时，同时检查桌面端和移动端。
- 如果结果与预期不同，请记录确切失败步骤。
重要限制和操作说明
- 成功保存确认的是已持久化，而不是每一个下游同步或公开更新都已完成。
- 工作区权限可能会隐藏某个区域，或允许读取但不允许更改。
- 不要将易变的目录、账户或客户事实复制到叙述性内容中作为变通办法。
- 仅测试对当前公司可见且已配置的受支持功能。
- 将账户访问方面的更改与不相关的 Agent、Knowledge、目录、Inbox 或 Helpdesk 工作分开。
验证结果
- 每位活跃成员都有已批准的业务需要。
- 待处理邀请都有负责人和到期决定。
- 角色与当前职责匹配。
- 受影响的用户可以登录，并且只能看到预期区域。
简要记录你测试了什么、使用了哪种客户场景以及发生了哪些变化。这会让后续故障排查更加精确，也能帮助其他团队成员在不依赖记忆的情况下复现结果。
故障排查
团队成员已接受邀请，但无法访问公司
检查已接受账户的电子邮件是否与邀请及预期登录方式匹配，然后检查实际成员资格和角色。避免向不同身份重复发送邀请。
角色更改后访问权限仍然保留
让用户刷新页面或开始新的会话，然后验证实际权限。如果不匹配仍然存在，请连同公司、用户、角色和受影响部分一起升级处理。