在SaaS产品架构设计中，员工账号管理看似基础却暗藏玄机。本文从业务对象关系、账号属性设计到离职账号处理，系统解析如何构建既符合真实组织逻辑又兼顾系统易用性的账号管理体系。通过详实的架构图示和属性分析，揭示员工账号作为权限管理与组织架构核心枢纽的关键作用。

01 前言

我们前面几篇讲到了权限管理、组织架构管理，实际上最终都是为了便于管理人员，也就是权限管理和组织架构管理都是员工账号模块的支撑模块。操作次序上，为了新增一名员工的账号，也需要先完成角色和组织架构的录入后，才能添加员工账号。员工账号看似简单，但是也有很多细节需要根据具体的业务情况进行区别设计。

02 员工账号与业务对象关系

我们先来看看员工账号会和哪些业务对象有关系。

这里我们需要强调一个观念，那就是我们软件产品中的业务对象实际上应该要还原真实世界的对象，包括他们之间的关系。当然，在软件产品中我们可以通过添加一定的约束条件来简化业务对象关系，提高系统的易用性。比如，在我们的真实世界里，实际上是是组织机构、岗位和员工，对应到软件产品才变成了员工账号、角色这些业务对象。我们来看一下具体的关系：

• 企业有多个组织机构，通常来说，一名员工会只属于一个部门（这是约束条件）。当然，也有例外的情况，比如我曾经就职的一个部门在集团内部有两个招牌（也就是两个部门），分属于不同的子公司。这个时候，员工就可能会属于多个部门。
• 企业内部根据职能需要，会设立不同的岗位，员工在入职的时候通常也会有明确的一个岗位。也就是，员工通常只会有一个岗位。但是，现实情况是存在一人兼任多岗的情况，比如市场副总兼任市场总监，总经理助理兼任办公室主任之类的。

• 在软件产品里，我们可能会需要建立员工档案（假设有 HR 的模块），也可能不需要。从业务逻辑上来说，实际上员工和员工账号不能直接划等号。因为，有些员工不一定有账号。所以，具体情况要具体分析，但是我们设计的时候，需要能够确定员工账号对应是哪一位员工。通常会通过一个唯一性的字段来区别，最好的字段就是身份证号，退而求其次则是手机号和邮箱。
• 员工账号才会和具体的角色关联，以便给员工开通相应的权限。在设计上，建议是支持一个员工可以有多个角色，一个是可以减少角色的数量，另一个则是满足我们上面讲到的“一人多岗”的情形。
• 员工账号会和很多其他业务对象发生关系，这主要体现在操作痕迹追溯上，比如添加人、最后修改人、操作日志等等。这块是可以有相对通用的设计方法的。

03 员工账号属性

我们再来梳理一下一个员工账号有哪些属性，当然，具体到实际的产品设计可以酌情增减。比如到 SaaS 平台侧，为了节省开发资源，就可以按最简洁的方式设计。而如果是租户侧，则需要考虑客户群体是否需要做精细化管理。对于一个企业员工账号，主要的属性如下：

• 账号：要求整个系统唯一，国内大多才用手机号，国外邮箱更多一些；
• 密码：密码可以是后台开通的时候，按一定的规则生成初始密码，然后要求首次登录更改初始密码。这里需要注意一点的是安全性。密码不能明文存储这已经是常识了，但是如果不放心还是要在需求文档中明确。通常，密码在数据库里使用不可逆的加密方式存储的 —— 也就是不能通过密文破解出密码原文。技术上通常的做法是用密码明文+随机字符组合后，再用 MD5、SHA256等算法进行加密得到密文。此外，就是用户输入的密码尽可能不要明文传输，避免在网络上被截取。这种一方面可以通过 HTTPS 实现加密传输，另外技术上也可以将明文转换为密文提交。
• 姓名：员工姓名，如果要考虑员工姓名的排序，那么推荐是提取员工姓名的首字母用于排序。这个在需求文档说清楚即可。在数据库是需要额外增加字段的。
• 唯一标识：比如身份证号、手机号（如果手机号作为账号也可以不要这个属性）或邮箱。公司内部有工号系统也可以用工号。
• 所属机构：也就是所属的组织机构，可以根据需要决定是否要支持一名员工属于多个机构。
• 所属角色：也就是为员工账号分配权限，这里建议是支持一名员工可以有多个角色，以减少角色的数量。
• 其他信息：可以根据自身的业务需要去增加，比如性别、生日、岗位等等。
• 备注：对于主要的业务对象，建议统一增加一个非必填的备注字段，以便增加一些额外的说明，避免每次都让开发增加字段。

04 员工详情

员工账号因为关联到很多数据，为了便于全面了解员工在系统中的权限、操作记录，因此员工详情中最好是能够提供业务管控所需要的全面信息，下面为一个示例的员工详情页面原型。

05 员工账号删除处理

员工离职后，就会涉及到员工账号删除处理。由于员工在系统中会留下很多操作痕迹，因此，在员工账号删除上需要做额外的处理。

1、离职交接

员工可能在离职时，手里还有一些业务没有完结，这个时候就会涉及到交接。对于 SaaS 产品来说，就是交接数据归属，比如客户负责人转移，售后负责人转移等等。这种情况下，需要列举出离职人员涉及的数据，然后逐项或批量指定新的交接员工，以保证离职后在系统中的业务有人接手。这里需要注意，离职人员账号应该禁止登录系统。

2、是否可以恢复

如果有离职这个状态，并且有离职交接这样的严格程序，那么账号恢不恢复问题都不大。因为这种情况下，肯定是离职后才能删除账号的。如果没有上述的程序，那么建议是支持提供恢复操作，也就是删除后账号可以恢复。这主要是防止误删，因为账号和人员对应，有唯一性。如果是误删除无法恢复的话，那么再给同一个人开通账号是无法开通的，这种情况下还得请技术来处理，就比较麻烦了。

3、历史数据查看

第三个是历史数据查看的问题，很多产品的设计是无法筛选出已删除人员操作的数据的，这其实不利于离职追溯。通常，在诸如添加人、最后修改人以及操作日志中，除了有人员账号的 id 之外，还需要记录操作人的姓名。这样的话，我们可以通过操作人的姓名去找到对应人员的操作记录。比如，我见过的一个场景就是一个文章管理模块，会有发布者这样一个筛选。这里就需要支持筛选出已经删除账号的发布数据。具体交互上，我们倒是可以做细化，比如将在职和离职的分组展示，如下图所示，会更加清晰。