一、限制登录时间
本单元先创建一个全新的 Trailhead Playground，然后在 Support 配置文件上限制登录时间。
学完本项目，你将能够：限制用户登录组织的时间、确定用户对对象的访问级别、用角色层级/共享/团队设置数据访问模型、控制用户对字段的访问级别。
新建 Trailhead Playground
AW Computing 的 CEO Jon Wiseman 有一些安全担忧，想降低 Salesforce 中数据被未授权访问的风险。不是组织里的每个人都该有相同的访问级别——支持用户只能在公司标准办公时间登录，其他用户应 24/7 可访问、能在公司网络与 VPN 上登录。Jon 请你这位优秀的管理员来解决这个问题。本项目里，你会学习通过精确控制用户在 Salesforce 中能访问哪些数据来保护组织。
上图展示了访问的层级模型——Field 嵌套在 Record 里、Record 嵌套在 Object 里。本项目的组织架构图会反复出现，用于说明如何在每个层级设置访问。
始终在隔离环境测试安全配置：为本模块创建一个全新的 Trailhead Playground（滚动到底部，点击 playground 名称，再点 Create Playground，通常需 3-4 分钟）。必须用全新的 playground——用现有 org 可能在本项目步骤中遇到问题。一个全新 playground 能防止误配置把你锁在真实 org 之外，也为安全配置提供干净起点，这个 playground 会贯穿全部五个单元使用。
在 Support 配置文件上限制登录时间
按配置文件控制用户何时能访问 Salesforce。点击 Setup 齿轮 → Setup → Quick Find 输入 Profiles → 选择 Profiles → 点击 Custom: Support Profile，然后配置 Login Hours（登录时间）：
- 周日（Sunday）：12:00 AM 至 12:00 AM（全天不可登录）
- 周一至周五（Monday–Friday）：8:00 AM 至 6:00 PM
- 周六（Saturday）：12:00 AM 至 12:00 AM（全天不可登录）
点击 Save。这样支持用户只能在公司标准办公时间（工作日上午 8 点到下午 6 点）登录，其余时间被禁止访问。
用例：支持团队成员只应在排班时段访问 Salesforce，这减少了非工作时间的攻击面、强制了工作排班合规。登录时间限制是基于身份访问控制的第一层防线，它与 MFA、IP 限制等更强控制互补。完成后进入下一步，继续通过添加新用户、用权限集设置安全级别来增强 AW Computing org 的安全。
二、创建新用户并允许删除账户
本单元更新到增强配置文件界面，创建无删除权限的自定义配置文件，设置登录访问策略，并通过权限集授予账户删除权限。
更新到增强配置文件界面
启用 Enhanced Profile User Interface 以获得更直观的配置文件管理体验：从 Setup 的 Quick Find 输入 User Management，选择 User Management Settings，把 Enhanced Profile User Interface 开关切到 Enabled。
好处：更精简的配置文件编辑、更轻松的权限浏览与分配、与 Setup 其余部分一致的现代界面。这是一次性 org 设置，之后所有配置文件配置都使用增强界面。
创建无删除权限的新配置文件
创建一个显式禁止删除账户的自定义配置文件。背景：你正在参加与 CEO 和高管团队的安全与数据访问审查会议，首要议程是确保所有用户都拥有适合其岗位的对象权限。CEO 希望用户能访问其工作所需的对象，但要把删除记录的能力限制在 Executive Users 和 Support 团队。VP of Services 的 Noah Larkin 正在帮忙清理记录，需要临时删除 Account 的权限。
创建无删除权限的配置文件：Setup → Profiles → 点击顶部字母选择器里的 S → 在 Standard Platform User 旁点 Clone → Profile Name 填 Standard Profile - No Acct Delete → Save。打开该配置文件的 overview 后，在 Apps 区点 Object Settings → Accounts → Edit，在 Object Permissions 里取消 Delete（此时应只剩 Read、Create、Edit 打勾）→ Save。
为什么克隆而不是直接改标准配置文件？标准配置文件不能删除或重命名；自定义配置文件给你完整控制，也更容易随时间审计与管理。结果：分配给这个配置文件的用户无法删除 Account 记录——无论其他任何权限如何，这是配置文件级别的限制，先于共享规则或权限集评估。
设置登录访问策略并创建新用户
设置登录访问策略：Setup → Login Access Policies → 勾选 Administrators Can Log in as Any User 旁的 Enabled → Save。这样管理员就能以其他用户身份登录来测试权限。
创建新用户：Setup → Users → New。由于 Trailhead playground 的 Salesforce Platform 许可数量有限，先停用两个用户释放许可——在 Users 里点 Maya Lorrette 旁的 Edit，取消 Active 复选框，警告消息点 OK 再 Save；对 Ted Kim 重复同样操作。现在有了两个额外的 Salesforce Platform 许可。
创建新用户（填写如下字段）：
- User License：Salesforce Platform
- Profile：Standard Profile - No Acct Delete
- Role：Western Sales Team（先设 User License 再设 Profile；选完 license 和 profile 后，Western Sales Team 会是 Role 列表最后一项）
- Time Zone：Pacific Time (America/Los_Angeles)
- Locale：English (United States)
- Language：English
- Email：你自己的邮箱
- Username：自动填充为邮箱，按公式替换为"名字首字母 + 姓 + @ + 你的首字母 + 喜欢的颜色 + 数字 + .com"（如
nlarkin@wbpurple.com、adaniels@wbyellow.com）
创建两个新用户：Noah Larkin（Role 选 Customer Support, International）和 Amy Daniels（Role 选 Western Sales Team），都分配 Standard Profile - No Acct Delete 配置文件。
测试很关键：以测试用户登录，验证 Account 记录上的 Delete 按钮被禁用或返回错误，确认配置文件级限制在通过权限集扩展权限前已生效。
用权限集允许用户删除账户
权限集在配置文件基线之上授予额外权限。Setup → Permission Sets → New，Label 填 Delete Accounts、Description 填 Grants Delete Accounts permission（描述必填，用于关联适用的许可）、选择 Salesforce Platform 用户类型 → Save。在 Apps 区点 Object Settings → Accounts → Edit，勾选 Object Permissions 下的 Delete（Edit 和 Read 会自动勾选）→ Save。
然后点 Manage Assignments → Add Assignments，在 Action 列勾选 Noah Larkin → Next → Assign → Done。
以 Noah Larkin 登录测试：Setup → Users → 在 action 列点 Noah Larkin 旁的 Login → App Launcher 点 Accounts → List View 选 All Accounts → 点 GenePoint，现在 Account Detail 页面顶部出现了 Delete 按钮（因为 Noah 拥有 Account: Delete 权限集）。测试完点页面顶部 Log out as Noah Larkin。
这就是累加式安全模型：配置文件定义"下限"（禁止删除账户），权限集抬高"上限"（允许删除账户），两者叠加后用户可以删除账户。最佳实践：在配置文件级做限制、通过权限集授予例外——更干净、更可审计、更易管理。
三、设置组织级默认值并创建角色层级
本单元创建自定义对象，设置组织级默认值限制访问，构建角色层级，并把用户分配到角色。
创建自定义对象并设置组织级默认值
组织级默认值（Organization-Wide Defaults，OWD）是一个对象所有记录的基础访问级别。为招聘场景创建三个自定义对象：Applicant（申请人）、Interviewer（面试官）、Position（职位）。Setup → Object Manager → Create → Custom Object，为每个对象设置 Label、Plural Label、勾选 Starts with vowel sound、Record Name 用 Text 类型、勾选 Allow Reports 与 Allow Search。
在 Position 对象上创建 Status 字段：Fields & Relationships → New → Picklist，Field Label 填 Status，值输入 New、Open、Closed（每行一个），勾选 Restrict picklist to the values defined in the value set。
设置 OWD：Setup → Sharing Settings → Edit，把 Applicant、Interviewer、Position 的默认内部访问设为 Private → Save（会收到"One or more sharing operations has been initiated"的通知）。三种 OWD 级别：Private（只有记录所有者 + 角色层级之上的人可访问，最严格）、Public Read Only（人人可见、只有所有者可编辑）、Public Read/Write（人人可见可编辑）。对敏感的招聘数据，Private 是正确的选择。
OWD 是基础——共享规则和角色层级从这个基线开放访问。OWD 从不授予访问，它只限制；它是共享模型的地板。
创建角色层级
角色层级在 Salesforce 中反映你的组织架构图，垂直控制记录访问。Setup → Roles → Set Up Roles → Expand All，在 CEO 下方点 Add Role，逐个创建角色（每个都设 Label 与 "Role Name as displayed on reports"）：
- VP of Services（直接在 CEO 下）
- Accounts Receivable（report to：VP of Services）
- Customer Support Director（report to：VP of Services）
- Customer Support Rep（report to：Customer Support Director）
- Sales Engineer（report to：Director, Direct Sales）
- Recruiter（report to：SVP, Human Resources）
角色层级规则：层级较高的用户能访问其下方用户拥有的记录（针对 Private OWD）；同级用户不能访问彼此的记录；下方用户不能访问上方拥有的记录。这模拟了真实的管理链——经理自动看到团队的记录，访问只沿层级向下流动。
为用户分配角色
创建层级后，把每个用户分配到对应角色。Setup → Roles → Set Up Roles → Expand All，在每个角色旁点 Assign，从 Available Users 选对应用户 → Add → Save：
- VP of Services → Noah Larkin
- Accounts Receivable → Maya Lorrette
- Sales Engineer → Amy Daniels
- Recruiter → Ted Kim
- Customer Support Rep → 你自己（你的名字）
分配后立即生效：经理自动看到其下方用户拥有的所有记录，招聘人员只看到自己的记录 + 通过共享规则共享的记录。角色分配是即时的、无需重算，新记录自动遵循层级。现在那些记录已准备好被共享——下一步设置机会共享规则，让招聘团队成员能共享申请人的信息。
四、创建共享规则
本单元创建共享规则授予水平访问——在角色层级覆盖不到的平级群体之间共享记录。
创建共享规则
共享规则在同级群体之间水平授予访问。当前信息只对记录所有者与角色层级之上的人可见，所以要为其他需要访问的用户创建共享规则。两种类型：基于条件的共享规则（共享满足特定字段条件的记录）与基于所有者的共享规则（把特定用户/组拥有的记录共享给其他用户/组）。
先创建机会共享规则：Setup → Sharing Settings → Manage sharing settings for 选 Opportunities，Rule Type 选 Based on criteria，Criteria 设 Field: Won、Operator: Equals、Value: True，Share with 选 Roles: Accounts Receivable，Access Level 选 Read/Write → Save。这条规则让应收账款团队能查看已赢得（Won）的机会。
共享规则从 OWD 基线开放访问，它们从不限制、只授予额外访问。角色层级 = 垂直，共享规则 = 水平。
为招聘只读用户创建共享规则
出于保密原因，Applicant、Interviewer、Position 记录已设为 Private。但招聘团队成员需要协作彼此的记录，VP 需要所有开放职位的 Read 访问。创建三条基于所有者的共享规则，让招聘用户（Recruiter 角色）能读取彼此的记录（Manage sharing settings for 分别选 Applicant、Interviewer、Position，Rule Type 选 Based on record owner，owned by members of 选 Roles: Recruiter，Share with 选 Roles: Recruiter）：
- Applicant：Access Level Read Only
- Interviewer：Access Level Read Only
- Position：Access Level Read/Write
接着创建 VPs 公共组：Setup → Public Groups → New，Label 与 Group Name 都填 VPs，从 search picklist 选 Roles，选择所有 VP 角色加入 Selected Members → Save。
再创建基于条件的共享规则给 VP 只读访问所有开放职位：Sharing Settings → Position，Rule Type 选 Based on criteria，Criteria 设 Field: Status、Operator: equals、Value: Open，Share with 选 Public Groups: VPs，Access Level 选 Read Only → Save。
公共组抽象很有用——团队成员变动时只更新组成员，不用改动共享规则。"谁获得访问"（组）与"如何授予访问"（规则）分离，让持续管理更简单。现在招聘团队和 VP 都能访问所需的申请人与开放职位信息了。
五、设置账户团队
本单元收尾——配置账户团队（Account Teams），一种灵活、基于团队的记录共享方式。
大功告成
销售在 AW Computing 是一项协作活动。除了销售代表，客户支持代表也参与客户账户，需要访问对应的机会、案例与联系人。设置账户团队让销售代表、工程师、客户支持代表与咨询代表都能访问他们正在处理的账户相关的机会与案例。
启用账户团队：Setup → Account Teams → Enable Account Teams → 勾选 Account Teams Enabled → Save → 勾选 Account Layout（把 Account Team 相关列表加入页面布局）→ 勾选 Add to users' customized related lists → Save。添加团队角色：点 Team Roles → New，在文本区输入 Customer Support Rep 与 Sales Engineer（每行一个）→ Save。
创建默认账户团队：点击右上角用户图标 → Settings → 左侧点 Advanced User Details → 在 Default Account Team 相关列表点 Add，添加两个 Team Member，各自的 Account Access、Opportunity Access、Case Access 都设为 Read/Write，Team Role 分别为 Customer Support Rep 与 Sales Engineer → Save。
把默认团队加入账户：App Launcher → Sales → Accounts 标签 → All Accounts → 点 Edge Communications → 在 Account Team 相关列表点 Add Default Team（若看不到 Account Team，去 Setup → Edit Object → Page Layouts → Account (Marketing) layout → Related Lists 把 Account Team 组件拖到布局上）。
至此你实现了六层安全架构：登录安全（配置文件上的登录时间与 IP 范围限制）、配置文件与权限集安全（自定义配置文件设基线限制、权限集做定向授权）、组织级默认值（敏感自定义对象设 Private）、角色层级（沿管理链的垂直访问，确保每个用户只访问其角色所需信息）、共享规则（平级群体的水平访问，让用户协作记录）、账户团队（灵活的团队级记录共享）。纵深防御——每一层增加保护，没有单一控制承担全部安全责任。CEO Jon Wiseman 现在可以安心了，干得漂亮，优秀的管理员！