角色(Roles)

角色用于定义 Finger Manager 后台用户在系统中的职责类型和权限集合。

机构可以根据内部岗位和管理结构创建不同角色,并为每个角色配置对应的功能权限、数据权限及操作权限。

当后台用户被分配某个角色后,系统会根据该角色决定其可以访问哪些模块、查看哪些数据,以及执行哪些操作。

角色是 Finger Manager 权限管理体系中的核心组成部分。

什么是角色

角色(Role)可以理解为一组预先定义好的权限配置。

例如,机构可以创建 Super Admin、Administrator、Operations、Customer Service、Trading Operations、Risk Management、Compliance、Finance 和 Read Only 等角色。

不同角色对应不同岗位和职责。例如 Operations 主要负责产品展示、内容运营和通知发布;Compliance 主要负责客户审核、KYC / KYB 和合规相关工作;Customer Service 主要负责客户资料查看、客户沟通和服务处理。

通过角色,机构无需为每一名员工重复配置全部权限。

01 创建角色

拥有角色管理权限的管理员可以在 Finger Manager 中创建新的角色。

创建角色时可以配置角色名称、角色说明、所属组织、角色状态、功能权限、数据权限和操作权限。

例如角色名称为 Operations,角色说明为负责 App 内容运营、通知发布及产品展示管理。创建完成后,即可将该角色分配给对应后台用户。

02 配置角色权限

每个角色可以拥有不同的权限组合。

权限通常可以分为功能权限、操作权限和数据权限。

功能权限决定角色可以访问哪些系统模块,例如工作台、市场与产品管理、客户管理、交易管理、内容与通知、组织与权限、系统设置和报表与分析。

操作权限决定角色在模块中可以执行哪些操作,例如查看、新增、编辑、删除、发布、审批、导出和管理。

数据权限决定角色可以访问哪些数据,例如全部组织数据、当前组织数据、指定团队数据、指定客户数据、指定市场数据和指定 Desk 数据。

通过这三个维度,可以建立更加细致的权限体系。

03 角色与用户

角色创建完成后,可以分配给后台用户。

例如 Aki Tanaka 的角色为 Operations,系统将根据 Operations 角色自动授予对应权限。

如果该角色可以查看产品、编辑 Banner、发布公告和创建 Push Notification,那么 Aki Tanaka 登录 Finger Manager 后即可执行这些操作。如果角色没有组织管理权限,则相关功能不会开放。

04 一个角色可以分配给多个用户

同一个角色可以同时分配给多名后台用户。

例如 Customer Service 可以分配给 User A、User B、User C 和 User D,这四名用户将获得相同的基础权限。

如果未来需要调整客服岗位的权限,只需要修改 Customer Service 角色即可,无需逐个修改每一位用户。

05 一个用户可以拥有多个角色

根据机构的管理方式,一个用户也可以同时拥有多个角色。

例如某位员工同时负责 Operations 和 Customer Service,则可以同时获得两个角色对应的权限。

系统会根据角色组合计算该用户最终可以访问的功能范围。这种方式适合跨部门或兼任多个岗位的后台人员。

06 系统预设角色

Super Admin 最高级别管理员,通常可以管理组织、后台用户、创建角色、修改权限、管理系统配置和查看全部业务数据。
Administrator 负责日常后台管理,可以根据机构配置拥有较高权限,但不一定拥有全部系统级权限。
Operations 主要负责产品展示、Banner、公告、弹窗、跑马灯、Push Notification、用户分组和活动配置。
Customer Service 主要负责查看客户、查看客户资料、查看账户状态、发送站内通知和处理客户事项。
Trading Operations 主要负责查看订单、查看持仓、查看交易信号、查看交易状态和处理相关业务事项。
Compliance 主要负责客户资料、KYC / KYB、审核任务、合规记录和操作日志。
Finance 可以根据机构需求查看账单、收费信息、财务相关数据、结算记录和报表。
Read Only 只允许查看被授权的数据,不能进行新增、编辑、删除、发布或审批。适合审计、管理层查看或外部观察人员。

07 组织级角色

角色可以归属于指定 Organization。

例如 Japan Entity 拥有自己的 Admin、Operations 和 Compliance;Hong Kong Entity 也可以拥有 Admin、Operations 和 Compliance。

即使角色名称相同,不同组织也可以设置不同权限。例如 Japan Compliance 与 Hong Kong Compliance 可以根据当地业务要求配置不同访问范围。

08 全局角色

对于集团级管理人员,可以配置跨组织的全局角色。

例如 Group Administrator 可以访问 Japan Entity、Hong Kong Entity 和 Singapore Entity,并拥有跨组织查看或管理权限。

普通组织角色则只能访问所属组织范围内的数据。

09 角色状态

角色可以设置不同状态,例如 Active 和 Disabled。

Active 表示角色正常使用;Disabled 表示角色暂时停用。

当角色被停用后,新用户不能继续使用该角色,已经分配该角色的用户也可以根据系统规则失去对应权限。对于不再使用但需要保留历史记录的角色,可以选择停用而不是直接删除。

10 修改角色

管理员可以随时修改已有角色的权限。

例如原本 Operations 角色可以查看客户和发布通知,之后需要增加管理用户分组,管理员只需要修改 Operations 角色。

修改完成后,所有拥有该角色的用户都将按照新的权限配置执行。因此,在修改角色权限前,应确认可能受到影响的用户范围。

11 复制角色

当新角色与现有角色权限比较接近时,可以基于已有角色进行复制。

例如已有 Operations,需要建立 Senior Operations,可以复制原有角色,再增加审批权限、删除权限或更大的数据访问范围。

这样可以减少重复配置。

12 最小权限原则

建议机构按照最小权限原则(Principle of Least Privilege)创建角色,即每个角色只拥有完成对应岗位工作所必需的权限。

例如客服人员不需要系统配置权限,运营人员不需要修改组织结构,普通交易运营人员不需要角色管理权限。

通过合理划分角色,可以降低误操作风险、数据泄露风险、权限滥用风险和内部管理风险。

13 角色变更

当员工岗位发生变化时,可以直接调整其角色。

例如员工原本属于 Customer Service,调岗后改为 Operations,管理员可以移除原有角色,再分配新的角色。

无需重新创建后台账户。

14 角色与审批流程

对于重要业务,可以将角色用于审批流程。

例如 Operations 创建通知 → Manager Review 审核 → Administrator 批准 → 系统正式发布。

或者 Trading Operations 发起操作 → Risk Management 审核 → 执行最终处理。通过不同角色之间的职责分离,可以建立更规范的内部控制流程。

15 角色与操作日志

Finger Manager 可以记录角色相关操作。

例如创建角色、修改角色、修改权限、分配角色、移除角色和停用角色。

系统可以记录操作人、操作时间、角色名称、修改内容和操作结果,便于机构进行安全审计和问题排查。

角色管理逻辑

角色管理逻辑可以理解为:创建角色 → 填写角色名称与说明 → 设置所属组织 → 配置功能权限 → 配置操作权限 → 配置数据范围 → 保存角色 → 将角色分配给后台用户 → 用户登录 Finger Manager → 系统读取角色 → 加载对应权限 → 用户只能执行被授权的操作。

典型应用场景

部门岗位管理 为不同部门建立 Operations、Compliance、Customer Service 等角色。
集团权限管理 为总部建立跨组织角色,为各地区机构建立独立角色。
新员工入职 新员工创建后台账户后,直接分配现有角色即可完成权限配置。
员工调岗 修改用户角色即可快速调整其后台权限。
临时访问 可以建立 Read Only 或 Temporary Role,为特定人员提供有限访问权限。

角色属于 Finger Manager 组织与权限体系中的权限集合单元。

机构可以通过角色将复杂的功能权限、操作权限和数据权限进行统一配置,再将角色分配给不同后台用户。

通过角色管理,可以显著减少逐个用户配置权限的工作量,并使机构内部的岗位职责、数据访问范围和操作边界更加清晰。