构建 Skill Align – 第3部分：用户、应用、配置文件和权限集

Source: Dev.to

请提供您希望翻译的完整文本内容，我将按照要求保留原始链接、格式、Markdown 语法以及代码块，仅翻译正文部分。

谁会使用此系统——他们应该看到什么？

在 Salesforce 中，定义用户和访问权限与定义对象同样重要。

为什么我创建了三个用户

Skill Align 反映了真实组织，所以我创建了三个用户，每个代表不同的业务角色，拥有不同的职责和控制级别。

HR – 控制者

HR 负责：

• 创建员工记录
• 管理技能
• 确认分配

HR 需要系统级的完整访问权限。由于 Developer Org 已经提供了默认的 System Administrator 用户，我使用它来代表 HR。这样既不消耗额外的许可证，又能保持完整的管理控制。

项目经理 – 决策者

项目经理：

• 创建项目记录
• 定义所需技能
• 审核候选人

他们 不需要：

• 系统配置访问
• 管理权限
• 不受限制的数据可见性

他们的访问必须保持业务导向且仅限于项目范围。

员工 – 贡献者

员工：

• 查看自己的技能
• 更新信心等级
• 查看项目分配

他们 不应：

• 自行分配
• 修改其他员工
• 删除重要记录

他们的访问必须受限且自我封闭。

许可证限制与配置文件策略

最初，我将 Project Manager（项目经理）和 Employee（员工）都分配到 Standard User（标准用户）配置文件。直接编辑 Standard User 并不是一种干净的架构实践；它是 Salesforce 提供的通用基线配置文件，过度修改它可能在以后导致维护复杂性——尤其是当组织规模扩大或引入额外用例时。

与其修改共享的基础，我创建了一个专用的自定义配置文件：Skill Align User（技能对齐用户）。该配置文件成为项目经理和员工用户的受控基线。（我们稍后将详细了解配置文件。）

为什么要创建新配置文件？

• 隔离所有项目特定的配置
• 保持干净且可扩展的架构
• 保留未来增强的灵活性

最终结构

• HR → 系统管理员配置文件
• Manager → Skill Align User 配置文件
• Employee → Skill Align User 配置文件

创建三个独立的 Lightning 应用

为了提升可用性并模拟真实的企业结构，我创建了：

• HR 应用
• 经理应用
• 员工应用

每个应用仅包含相关的标签页和对象。

什么是标签页？

Salesforce 中的标签页是一种导航元素，可用于访问对象或功能。例如：

• 员工标签页 → 打开员工记录
• 项目标签页 → 打开项目记录

标签页决定用户在应用界面中可以访问的内容。

下一步挑战

此时，经理和员工共享相同的配置文件（Skill Align User）。如果在配置文件层面分配多个应用程序，两位用户都会看到所有分配的应用程序，从而破坏基于角色的分离。

于是出现了架构问题：如何在不创建多个相似配置文件的情况下区分访问权限？ 这正是理解配置文件和权限集至关重要的地方。

Profiles vs Permission Sets

Profile

• 是强制性的（每个用户必须拥有一个）
• 定义基础权限
• 控制对象访问、字段级安全性和应用可见性

可以把 Profile 想象成建筑的基础。它应保持稳定且简洁。一个用户 → 一个 Profile。

Permission Set

• 是可选的
• 添加额外的权限
• 可以有选择地分配

可以把 Permission Set 看作是添加到基础上的模块化扩展。基础保持干净；只有在需要时才扩展功能。一个用户 → 多个 Permission Set（如有需要）。

最终方案

我有意将 Skill Align User 配置文件保持通用，然后创建了两个 Permission Sets：

• Manager App Access
• Employee App Access

在每个 Permission Set 中，我配置了：

• Lightning App 分配
• 必需的对象权限

然后我分配了：

• Manager Permission Set → 仅限项目经理
• Employee Permission Set → 仅限员工

这使得两个用户可以共享同一配置文件，同时看到完全不同的应用和访问级别。

为什么此设计很重要

• 避免修改标准用户
• 防止不必要的配置文件复制
• 在许可约束范围内工作
• 符合 Salesforce 安全最佳实践

企业级 Salesforce 设计倾向于：

• 最少的配置文件
• 使用权限集实现最大灵活性