Salesforce 共享与可见性架构师认证,考查声明式共享(OWD/Role Hierarchy/Sharing Rules)、Apex Managed Sharing(Share Object 结构:AccessLevel/RowCause/UserOrGroupId)、大数据量共享性能(Defer Sharing Calculations)和 Experience Cloud 共享模型,$400 考试费,需 3 年以上 Salesforce 实施经验,60 题/105 分钟/及格 62%。
Salesforce Application Architect 路径 4 张前置证里概念密度最高的一张——OWD/Role Hierarchy/Apex Managed Sharing 全盘吃透才能过,架构师路径必考,普通 Admin 碰不着。
先把考试形式、适合人群、备考时长和学习范围讲清楚,再决定要不要投入时间。
Salesforce Certified Sharing and Visibility Architect 是 Salesforce Application Architect 路径 4 张强制前置证之一(其余 3 张:Platform App Builder、Data Architect、Platform Developer I)。考试费 $400 USD——和 Data Architect、Integration Architect 同档,是 Salesforce 认证体系里除 CTA 之外最贵的一档,挂一次重考 $200。
考试细节:60 道题 + 105 分钟 + 62% 及格 + 纯英文。题型以复杂场景为主,几乎不考单知识点——题干会给你一个组织架构图 + 一堆业务规则("某保险公司有 5 个 BU、10 万条 Account 记录、外部合作方通过 Experience Cloud 登录……"),让你设计出兼顾安全性、性能、可维护性的共享方案。官方建议 3 年以上 Salesforce 实施经验,而且必须在生产项目里真实踩过 Sharing Rules 性能坑或写过 Apex Managed Sharing,光刷题基本必挂。
五大考域权重(2024 起稳定):Declarative Sharing(OWD/Role Hierarchy/Sharing Rules/Implicit Sharing)是绝对核心约占 35%,Programmatic Sharing(Apex Managed Sharing + with/without/inherited sharing 关键字)约 25%,Performance & Scalability(LDV、Defer Sharing Calculations、Group Membership Recalculation)约 15%,Visibility(FLS、Record Type、Permission Set)约 15%,Solution Design 综合场景约 10%。
和 Data Architect 的区别经常被搞混:Data Architect 考"数据模型怎么设计、LDV 怎么存",Sharing & Visibility 考"数据模型已经定了,怎么控制谁能看到哪条"。两张证都在 Application Architect 路径上,顺序上大部分人会先考 Data Architect 再考 Sharing & Visibility,因为共享设计必须基于已经定好的数据模型。维护方式和其他 Salesforce 证一样——每个 Release 在 Trailhead 做免费 maintenance 模块自动续期,不需要重考。
SF Sharing & Visibility 持证人的薪资区间、对应岗位、以及真实的职业影响。
这张证的价值不在"单证薪资",而在它是 Application Architect 路径的卡点
Salesforce 官方的 Application Architect 资格必须同时持有 4 张前置证:Platform App Builder、Data Architect、Sharing and Visibility Architect、Platform Developer I。任何一张不考都拿不到 Application Architect。而 Application Architect 又是 Technical Architect(CTA)的强制前置——换句话说,你想走 Salesforce 架构师的终极路线 CTA,这张证就是路径上绕不开的一步。
澳洲市场 Salesforce Solution Architect 的真实薪资带:Mid-level(3-5 年经验,持有 Application Architect)AUD 150,000-180,000;Senior(5-8 年,持有多张 Architect 系列)AUD 180,000-210,000;CTA 级别 AUD 220,000-280,000+(全澳 CTA 持证人 2026 年不到 30 位,稀缺度极高)。Deloitte Digital、Accenture Salesforce、Capgemini、Slalom、本地的 Davanti 这些 SF Partner 在 Solution Architect 岗位 JD 里基本都会把 Application Architect 列为 required 或 strongly preferred。
适合考的三类人:
已经持有 ADM-201 + Platform App Builder + Platform Developer I,准备走 Application Architect 路径的从业者:这是最自然的人群。建议顺序 Data Architect → Sharing & Visibility,因为共享设计必须基于数据模型。
在大型 Salesforce 实施项目里 own 过安全设计的 Senior Developer / Tech Lead:如果你做过百万级记录 Org 的 Sharing Rules 性能调优、写过 Apex Managed Sharing、或者设计过跨 BU 的数据隔离,这张证是把实战经验转成认证背书的直接方式。
咨询公司里被项目交付计划要求拿证的 Senior Consultant:很多 SF Partner 会把 Application Architect 作为 Senior → Principal Consultant 的晋升卡点。
不适合考的人:
过来人总结的分阶段备考节奏,按周拆分,不是空话。
从 Trailhead 官方 "Prepare for Your Sharing and Visibility Architect Credential" Trailmix 开始,但不要满足于 Trailhead 的演示题。在 Developer Edition Org 里手工搭一个 5 层 Role Hierarchy + 3 个 Public Group + 1 个 Account OWD=Private 的场景,然后创建 2 个 Owner-based Sharing Rule 和 1 个 Criteria-based Sharing Rule,用不同 Profile 的 User 登录实际验证访问结果。这一步的目标是建立肌肉记忆:任何"用户 X 能不能看到记录 Y"的题,都能按 OWD → Role Hierarchy → Sharing Rules → Manual/Apex Sharing 的四层顺序在 30 秒内走完。
这是大部分 Admin 转架构师的最大卡点。必须在 Dev Org 里真写一次完整的 Apex Managed Sharing:(1) 建一个自定义对象 OWD=Private;(2) 写一个 Apex class 往 __Share 对象里 insert 记录,指定 AccessLevel=Edit、UserOrGroupId=某个 User、RowCause=自定义的 Apex Sharing Reason(注意:标准对象只能用 RowCause="Manual",自定义对象才能建自定义 Reason);(3) 写一个 Trigger 在 Owner 变更时删除旧 Share 记录;(4) 手动触发 Sharing Recalculation 观察性能。跑通这一套之后再去做场景题,题干里的选项瞬间变得清晰。
大数据量共享是架构师差异化考点。重点吃透:(1) **Implicit Sharing 的 6 条规则**——Account Read 自动给你对应 Contact/Opportunity/Case 的 Read、Contact/Opp/Case 的 Edit 自动给你 parent Account 的 Read(这是 Salesforce 自动做的,你关都关不掉,很多"为什么这个 User 能看到这条记录"的题答案就是 Implicit Sharing);(2) **Defer Sharing Calculations** 的使用场景——批量数据导入 / 大规模 Role Hierarchy 重组前临时挂起共享重算避免系统卡死;(3) **Group Membership Lock** 和 Granular Locking 的区别;(4) Experience Cloud 下 Sharing Set(基于 Contact/Account 的自动共享)vs Sharing Group(Sharing Set 的结果再共享给内部 User)的适用条件。
最后阶段做 3-4 套完整模考(60 题 105 分钟),稳定 75% 以上再去考(62% 及格不能作为目标)。重点训练"题干读三遍才能理清业务规则"这类长题——Sharing & Visibility 的题干常常 8-12 行英文,包含组织结构、OWD 设置、多个 Sharing Rule、Profile 权限、Permission Set 等层层叠加的条件,必须养成用笔(或草稿纸)画出"User → Role → Profile → 哪些 Sharing 路径"的习惯。考前 3 天必读 Salesforce Security Implementation Guide 里 Sharing 章节,很多细节题直接从这份官方文档出。
过来人的备考时长、分数、以及踩过的坑。
这是我 Application Architect 路径 4 张前置证里考得最惊险的一张。前面 PD1/App Builder/Data Architect 都是一次 80%+ 过,这张低空飘过 71%。踩的最大坑是 **Apex Managed Sharing 的 RowCause**——我工作里写过 __Share insert,但一直用的是 Manual,考试里至少 5 道题在考"什么场景能建自定义 RowCause、标准对象能不能用自定义 RowCause",真坐下来才发现自定义 RowCause **只有自定义对象能用**,标准对象永远只能 Manual / Rule / ImplicitChild / Owner 这几个系统保留值。备考时一定要自己在 Dev Org 里两种对象都跑一遍。
工作日常就在做 Sharing 架构,备考重点放在了 Implicit Sharing 和 Defer Sharing Calculations 这种平时不常触碰的机制上。考场上最意外的是 **Implicit Sharing** 题目密度远超预期——至少 6-8 道题在考 Account-Contact/Opportunity/Case 的隐式继承,包括一道特别绕的题:"User 对 Account 只有 Read,对 Contact 有 Edit,问 User 最终对 Account 有什么权限" 答案是 Read(子对象 Edit 权限不会反向提升 parent 访问权,只会给 parent Read)。这种细节 Trailhead 根本不讲,必须读 Security Implementation Guide。
我是被公司晋升要求推着考的,项目经验主要在 Sales Cloud 配置,Apex 写得少。第一次模考 54%,最终考了 68%——刚过线 6 个点的惊险。最难的是 **Territory Management 2.0** 部分,我所有项目都没用过 Territory,全靠 Trailhead 模块硬啃。考试里大约 3-4 道题涉及 Territory,问的都是"Enterprise Territory Management 启用后 Account Sharing 如何被改写"这种细节。如果你项目里没用过 Territory,一定要额外花 3-4 天专门补这一块,否则送分题变送命题。
| SF Sharing & Visibility | SF Platform App Builder | CRT-450 | |
|---|---|---|---|
| 机构 | Salesforce | Salesforce | Salesforce |
| 级别 | 专业级 | 助理级 | 专业级 |
| 考试费 | $400 | $200 | $200 |
| 时长 | 105 min | 105 min | 105 min |
| 题量 | 60 | 60 | 60 |
| 有效期 | 3 年 | 3 年 | 3 年 |
**先过 Data Architect 再考 Sharing & Visibility** — 虽然没有硬性要求,但共享设计必须基于已定的数据模型。Application Architect 路径上的常见顺序是 Platform App Builder → PD1 → Data Architect → Sharing & Visibility,这个顺序能让你在学共享时不再被数据建模的基础概念分心。
**Security Implementation Guide 是必读官方文档** — Trailhead 只讲概念,细节考点(特别是 Implicit Sharing 的 6 条规则、Group Membership Lock、Sharing Recalculation 触发条件)只在 Salesforce 官方 Security Implementation Guide PDF 里完整讲过。考前 3 天通读 Sharing 章节比刷 100 道题更有用。
**Dev Org 必须真写过 Apex Managed Sharing** — 光看不写这一部分基本挂。最低限度:自己在 Dev Org 里建自定义对象、把 OWD 设成 Private、写 Apex 往 __Share 对象 insert 记录、建一个自定义 Sharing Reason、用不同 User 登录验证效果。整套流程 1-2 小时,能让你在考场上 Apex Sharing 题直接送分。
**场景题必须用画图法** — Sharing & Visibility 题干常常 10 行以上,涉及 3-5 个 User、多个 Role、多个 Profile、多个 Sharing Rule。建议在草稿纸(考场有白板)上画出 User → Role → Profile → 对象 OWD → 适用的 Sharing Rule 这张图,然后按 OWD → Hierarchy → Rules → Implicit → Apex/Manual 的顺序逐层判断,不要心算。
**关键词到答案的快速映射**:题干 "dynamic criteria that changes automatically" → Criteria-based Sharing Rule;"business can't be solved by declarative means" → Apex Managed Sharing;"bulk data load causes performance issues" → Defer Sharing Calculations;"external community users need access to specific account records" → Sharing Set;"sales reps work on specific accounts with granular permissions" → Account Team;"automatically cascade access down parent-child" → Implicit Sharing;"user in higher role automatically sees subordinate records" → Role Hierarchy。
**62% 是陷阱,不要用它当目标** — 这张证的模考分和实考分差距通常在 10-15 个点(因为真实考题比模考更注重场景综合判断)。模考稳定 78% 以上再考,低于 70% 绝对不要冲,$400 挂一次是 AUD 600+ 的真金白银。
**考前一周必看当前 Release Notes** — 和其他 Salesforce 证一样,每个 Release 后考试题库会加入 1-2 道新功能题。重点扫 Security, Privacy, and Identity 章节下的 Sharing 相关更新(比如最近几个 Release 的 Restriction Rules、Scoping Rules、User Access Policies 都是新考点)。
**把 Implicit Sharing 当成"可以配置的功能"** — Implicit Sharing 是 Salesforce 底层写死的行为,你既不能关闭也不能修改。6 条核心规则必背:(1) Account Read → 给你所有关联 Contact/Opp/Case 的 Read;(2) Contact/Opp/Case 的 Edit → 给你 parent Account 的 Read(只给 Read,不给 Edit);(3) Contact/Opp/Case 的 Owner 永远能看到 parent Account;(4) Account Team Member 对 Account 的访问权会 cascade 到 Opportunity;(5) Portal/Experience Cloud User 的 Account 访问会 cascade 给 Portal role 层级下的所有内部 User;(6) Opportunity Team 和 Case Team 有独立的 Implicit Sharing 路径。考场上"为什么这个 User 意外地能/不能看到某条记录"的题 50% 答案是 Implicit Sharing。
**把 Apex Managed Sharing 和普通 Apex DML 搞混** — Apex Managed Sharing 不是你用 `insert new Account__c()` 就算的。它特指:(1) 对象 OWD 必须是 Private 或 Public Read Only;(2) 你向该对象的 __Share 子对象(比如 MyObject__Share)insert 记录;(3) 指定 ParentId、UserOrGroupId、AccessLevel(Edit/Read/All)、RowCause。只有 **自定义对象** 才能用 Setup → Object Manager → Sharing Reasons 建自定义 RowCause,**标准对象只能用系统保留的 RowCause**(Manual / Rule / ImplicitChild / Owner / Team / Territory 等)。这是必考点,每次考试 3-4 道题。
**分不清 Public Group / Queue / Account Team / Sharing Rule 的使用边界** — (1) **Public Group**:用户/Role/其他 Group 的集合,用于 Sharing Rule 的目标("分享给这个 Group")或手动 Share 的接收方;(2) **Queue**:只给对象的 OwnerId 用——把 record assign 给 Queue 后,Queue members 都能 claim;常见于 Case、Lead、自定义对象;(3) **Account Team**:特定 Account 的 User 级别访问授权,每个 Member 可独立指定 Account/Contact/Opp/Case Access Level;(4) **Sharing Rule**:基于 Owner 或 Criteria 的自动共享规则。考题关键词映射:题干出现 "dynamic based on record criteria" → Criteria-based Sharing Rule;"record assigned to team, members work on it" → Queue;"same people always work on specific accounts" → Account Team;"group of users defined once used in many rules" → Public Group。
**OWD 设成 Public Read/Write 还想用 Sharing Rule 加权限** — 这是一个经典的概念反向题。Sharing Rules 的作用是"在 Private 或 Public Read Only 基础上额外开放访问权",**OWD 已经是 Public Read/Write 的对象上 Sharing Rule 完全无意义**(所有人已经能读写了)。反向的陷阱:Public Read/Write 对象也不能用 Sharing Rule 收紧权限——Salesforce Sharing 模型遵循"最宽松原则",任何规则只能加不能减。收紧权限的唯一方式是 Profile/Permission Set 的 Object Permissions 或降低 OWD 级别。
**Territory Management 1.0 vs Enterprise Territory Management 2.0 分不清** — 1.0 已经被官方弃用且不能在新 Org 启用,但考试依然会出历史题。2.0 的核心是:(1) 启用后会在 Account 对象上创建新的 Sharing 机制,Account 可以同时属于多个 Territory;(2) Territory Model 有 Planning / Active / Archived 三个状态,只有 Active 状态才影响真实数据访问;(3) Territory 的访问权可以 cascade 到关联的 Opportunity(通过 Opportunity-Territory 关联规则);(4) 启用 2.0 不能用 Change Set 部署,必须通过 Metadata API / SFDX。考场上"大型销售组织按区域分配 Account" 的场景题答案几乎都是 Enterprise Territory Management 2.0。
**不理解 Defer Sharing Calculations 的真实用途** — 这不是日常功能,而是在做**大规模数据操作**时的紧急刹车。典型使用场景:(1) 一次性导入 50 万条 Account 记录——如果不 defer,每插入一条就触发一次 Sharing Rule 重算,系统直接卡死;(2) 大规模 Role Hierarchy 重组——把 100 个用户从 Role A 移到 Role B,每次移动都触发 Group Membership Recalculation;(3) 批量修改 Owner。Defer 打开后 Salesforce 会暂停共享重算,操作完成后由管理员手动 Resume Sharing Calculations 一次性重算。考题关键词:"bulk data load", "role hierarchy reorganization", "system performance degrades during import" → 答案永远是 Defer Sharing Calculations。
**忘记 With Sharing / Without Sharing / Inherited Sharing 的默认行为** — Apex class 默认运行时**忽略当前用户的 Sharing Rules**(即等同于 without sharing),除非显式加 `with sharing` 关键字。(1) `with sharing`:强制尊重当前用户的记录级访问权和 FLS;(2) `without sharing`:忽略 Sharing,用于需要系统级访问的场景(如计算汇总值);(3) `inherited sharing`(Salesforce 从 v48.0 加入的推荐默认):跟随调用者的 sharing 模式,被 Aura/LWC/REST 直接调用时默认 with sharing,被其他 Apex 调用时继承。**考题里 Controller class 没写 with sharing 导致 Permission 问题** 是高频送分题。
51+ 练习题、章节学习路径、模考、错题复盘和 AI 导师都在备考页里。
进入备考页$39 起 · 前 2 章可免费试学