简介：面向Salesforce初学者、系统管理员与实施顾问，这份PDF手册以中文详细讲解CRM平台的核心概念与常用操作。内容覆盖账户、联系人、商机、市场活动、预测、个案、解决方案等核心数据对象，并从“入门”开始逐步深入到“组织设置”模块，包括设置组织信息与客户支持、维护组织简档、管理多种货币、添加和更新用户、配置用户角色与权限简档、设定登录限制与共享模式、自动共享规则、口令策略及会话安全性，同时提供自定义商机字段与阶段、获取Web商机、设置分配与升级规则等自动化能力。除管理配置外，还介绍了如何转移记录、批量删除数据、自定义选项卡与主页等实用操作，目录层级分明，可按需定位，便于随学随用。资源包共1个文件，为PDF格式电子文档，整体大小仅1.32MB，方便下载后离线阅读或打印。目前已有3205人学习使用，适合刚接触Salesforce的新手快速建立整体认识，也适合有经验的管理员对照检查系统设置。
1. 一份Salesforce手册，真正该带你走到的位置
打开Salesforce后台，很多第一次接触的人会有点发懵：左侧菜单一堆英文标签，对象、记录、权限、工作流、报表各占一摊，字段类型里有公式、有查找关系、有主从关系，单是搞清楚这些关系就要耗掉不少时间。这份使用手册想解决的问题，不是把人培养成通过认证的顾问级管理员，而是让你在真实业务里能独立完成一套闭环：梳理对象模型、配置权限、搭出可用的自动化流程、用外部工具导入并校验数据。简单说，读完能上手操作、能回答业务方“我们能不能这样配”的提问，遇到问题也知道该去查哪个配置页。这篇笔记适合四类人：刚接手Salesforce维护的开发者、业务系统负责人、负责内部工具落地的新手，以及想评估Salesforce运维成本的技术决策者。
2. 对象与字段：把业务说话的方式翻译成系统表结构
2.1 标准对象能覆盖大部分场景，别急着建自定义
Salesforce里最重要的设计决策往往不是“怎么写代码”，而是“用哪些对象来承载数据”。标准对象里最常用的四张表是：Account（客户/公司）、Contact（联系人）、Opportunity（商机）和Lead（潜在客户）。很多团队一开始就把Lead弃用，把所有线索硬塞进Contact，后期做转化分析时才发现丢掉了“线索来源”和“转化时间”两个关键维度。我的建议是：先按标准对象的语义走，除非业务确实有标准对象装不下的东西，否则不要一上来就建自定义对象。
判断标准很简单，打开「设置」-「对象管理器」，看每个标准对象的字段列表。Account里自带行业、客户级别、账户类型、父级账户；Contact里自带姓名、电话、邮件、部门、直接上级；Opportunity里自带阶段、金额、预计结单日期、赢单率。把这些字段真正用完，比多建十张自定义表更靠谱。比如“客户所属大区”这种字段，放在Account上，然后用Account的角色层级去表达“大区-分区-客户”的关系，而不是建一张独立的区域表再手动维护关系。
2.2 自定义对象与字段类型选择的四个关键点
当标准对象确实装不下时，再考虑自定义对象。这类对象命名建议带业务含义，例如“合同签订记录”，不要叫“数据表1”。新建入口在「对象管理器」-「新建」，这里我提醒四个容易忽略的点：
字段类型是第一个容易踩坑的地方。Salesforce的字段不止是“存什么”的问题，它还决定这个字段能不能被用于过滤、能不能出现在报表的汇总范围、能不能参与公式计算。举例来说，“金额”请用「金额」类型而非「数字」类型，否则报表里的“金额合计”不会正确汇总；“日期”用「日期」而不是「文本」，否则无法按月份做趋势分析。
第二个关键点是查找关系。Lookup（查找）是松耦合，Delete掉主记录时子记录的该字段会清空但子记录还在；Master-Detail（主从）是紧耦合，删除主记录会连带删除所有子记录，且权限继承主记录的访问层。常见做法是：业务上“离开上级就不存在”的数据用主从（比如商机的产品明细、订单的行项目），“可以独立存在”的用查找关系（比如联系人与客户的关联）。
第三个关键点是字段级安全性。新建字段时默认情况下只有系统管理员可见，其他Profile看不到。很多新手配完字段发现业务同事投诉“界面少了很多内容”，原因就是没在新字段的“字段级安全”里给对应Profile打勾。
第四个关键点是Record Types。同一张自定义表要支持不同流程时，用记录类型做区分。例如“合同”对象下面分“新签合同”和“续约合同”，不同记录类型可以配置不同的必填字段、不同的阶段值。这比建两张几乎一样的表更省维护成本。
2.3 用SOQL验证模型是否可用：关系查询与过滤器的最小示例
不管是用开发者控制台，还是通过Apex代码，SOQL（Salesforce对象查询语言）是验证对象模型最直接的手段。以下这段SOQL演示如何从Opportunity出发，穿过Contact关系找到客户联系人，并过滤出金额大于10万的商机：
SELECT Id, Name, Amount, StageName, Account.Name, Account.Parent.Name, Contact.FirstName + ' ' + Contact.LastName AS PrimaryContact FROM Opportunity WHERE Amount > 100000 AND RecordType.Name = 'NewBusiness' ORDER BY Amount DESC LIMIT 200逻辑说明：这条查询把Opportunity作为主表，用Account.Name和Account.Parent.Name两级查找关系，用Contact.FirstName和Contact.LastName拼接出联系人全名。FROM子句可以直接写关系字段的路径，这是SOQL相对SQL最方便的区别之一——不需要JOIN。WHERE部分同时使用了金额过滤和RecordType的名称过滤，注意RecordType必须写成RecordType.Name才能用名称过滤。
参数说明：LIMIT 200是查询行数的上限，开发调试时一定要加，避免大数据量下达不到查询超时限制而报错。ORDER BY Amount DESC用金额倒序，方便快速评估大商机。如果是通过开发者控制台执行，把LIMIT去掉后再跑一次能拿到完整报告，但生产环境里建议保留LIMIT做分页。
SOQL里最容易出错的地方是关系字段的写法：如果记录类型过滤写成RecordType.DeveloperName，那值也要换成API名称而不是显示名称。新字段的API名称会自动在字段标签后面追加“__c”后缀，写SOQL时用带__c的API名称，不是界面里显示的标签名。这个细节不知道时容易卡很久。
3. 权限体系：Salesforce里“能看见”和“能操作”是两层
3.1 Profile、Role、Org-Wide Defaults：先从三个词把模型搭起来
权限这块是整个系统里“看起来像玄学”的部分，其实核心就三个词：Profile（简档）、Role（角色）和Org-Wide Defaults（OWD）。
Profile管的是“能做什么”，比如能不能创建记录、能不能删除记录、能不能导出数据、能不能看到某个字段。它不区分数据范围——也就是说，Profile只决定操作能力，不决定数据范围。
Role管的是“能看见谁的数据”。Salesforce的角色层级是树状的：上级角色的用户默认能看到下级角色用户的数据，同级各看各的。这条规则是由“角色层级”这个隐藏机制控制的，只要两个用户分属不同分支，彼此就看不到对方创建的记录。
OWD是整个权限体系的底座。它在后台设置-共享设置里配置，决定“组织内部默认情况下，一条记录能被谁访问”。通常配置为：公开只读、公开读写、私有。这里有个关键原则：OWD设置为私有的记录，Profile就算有“查看所有数据”的权限也未必能绕开；OWD为公开读写的记录，Profile再怎么限制查看权限也拦不住。我习惯把它理解为“底层阀门”，Profile是“上层开关”，阀门关得比开关严时，开关再大也没用。
实际操作上，先定OWD再定Profile，最后才配共享规则。一个最小的上线检查清单是：
- 所有对象在OWD里先设置为“私有”；
- 测试用户都分到对应的Role层级里；
- Profile里只勾选“查看”级别的权限，不勾“编辑”；
- 特殊情况单独用共享规则放行。
3.2 共享规则与手动共享：特殊场景下的补充路径
共享规则解决的是“同一个Role层级或同一个Role分支之外，还要让部分人能看到某类记录”的场景。比如销售总监（Role层级较高）能看到所有人数据，但区域经理需要看到本区域所有销售的客户，此时就需要建一条共享规则，把“区域等于华东大区”的所有Account记录共享给“区域经理”这个角色及其下属角色。共享规则以“谁拥有或被共享的记录满足什么条件，就共享给谁”为表达逻辑，配置页面清晰，不太容易出错。
手动共享是最后的补充手段。记录详情页上点“共享”按钮，给特定用户或角色临时开放访问权限。它在同步报表时非常有用，缺点也很明显：单条手工授权不受共享规则管理，一旦人员变动，离职账号还可能残留这些手工共享的访问入口。每月清理一次手工共享记录是值得的习惯，可以在后台通过系统审计日志查出来，但不要频繁依赖。
3.3 最小化授权的检查清单：开发环境里跑一遍这个验证
权限配好之后，验证比配置更花时间。常用做法是创建两个测试用户，一个放在低层级、一个放在高层级，分别登录去验证能看到哪些记录。检查项至少包括：
- 新字段是否对目标Profile可见；
- 被同步到报表的记录，是否还能被报表使用者看到；
- 导出权限是否对普通员工关闭；
- 通过API批量导入数据的系统用户，是否只开了读取与导入权限，没有开删除权限；
- 离职账号是否被冻结而不是删除。
有一次我在模拟项目上帮某公司排查权限问题，发现销售们能看见其他人的商机金额，原因是OWD设置为“公开读写”，而所有Profile都勾选了“查看所有数据”。表面上明细看不出问题，但业务方天天反馈数据不隔离。最后把OWD改为“私有”，再把共享规则按区域配好，问题才彻底消失。这段经历让我养成一个习惯：每配一个对象，先把OWD关上，再一层层打开权限，而不是反过来，这样出问题的概率低很多。
4. 自动化与业务规则：把管理员从重复操作里解放出来的配置法
4.1 从工作流规则到Flow：选型逻辑与边界
Salesforce的自动化工具有好几个：工作流规则、Process Builder、Flow、Apex Trigger。从新项目选型来看，我的判断是：新项目尽量用Flow，存量系统能用Process Builder不动，老的工作流规则能迁移就迁移。Flow的维护界面更清晰，依赖关系可追溯，而且在Flow里可以做用户交互、创建记录、更新记录、调用外部系统，覆盖面远比工作流规则广。Process Builder的缺点是运行日志不直观，一个流程跑挂了排查成本高。
Flow也有边界。它不适合做非常复杂的循环嵌套，也不适合处理超大数据集（比如一次处理超过10万条记录）。碰到大量数据需要批量更新时，常见的做法仍是用匿名Apex或用命令行工具加载批处理任务。另外Flow Builder里不要把所有逻辑都塞进一个流程，建议按业务事件拆成多个独立Flow：订单审批一个、客户状态变化一个、合同到期提醒一个。这样单个流程的运行时间短，也不容易互相阻塞。
4.2 用Flow Builder搭一个审批场景的详细步骤
这里演示一个常见场景：商机金额超过50万时，自动发起审批，通过后把商机阶段改为“已审批”，并通知销售负责人。操作入口在「设置」-「流程」-「新建自动启动流程」。
第一步：设置触发条件。在“记录触发的流程”中选择对象为Opportunity，触发时机为“创建或更新”，条件编排为“金额大于500000”。注意判断字段时用“任何时间”而不是“更新后”，避免活儿还没干就把条件堵死。
第二步：添加“启动审批流程”元素。审批流程得先提前创建好：在「设置」-「审批」-「审批流程」中新建一个统一审批流程，指定审批步骤为“销售负责人审批”，审批记录类型为Opportunity，分配方式为“记录的所有者所在角色的上级用户”。回到Flow里，把这个审批流程选中，Flow运行时会自动创建审批请求并发送通知。
第三步：添加“更新记录”元素。该元素配置为更新当前记录，将StageName设置为“已审批”，更新时间在审批节点之后，并且勾选“仅在审批通过时执行”选项。
参数说明：在Flow里所有判断和赋值都要用“资源”来引用，像商机金额用{!Opportunity.Amount}，阶段字段用{!Opportunity.StageName}。表达能力没问题，但调试时要留意变量类型：金额字段是小数类型，判断条件里写“500000”没问题，如果写“500000.00”有时会报类型不匹配，这也是一个容易被忽略的细节。
搭完流程后，先用测试模式运行一次：添加一条金额为60万的商机记录，查看运行日志中审批步骤的状态是否为“已启动”，更新步骤是否被跳过。如果流程没有触发，第一件事是看流程的“触发条件”里的字段类型是否匹配，第二件事是看流程是否处于“部署”状态，Flow Builder里常常忘了点“部署”，结果流程只保存在草稿里。
4.3 自动化什么时候应该交给Apex：判断界限
Flow解决不了的问题才考虑Apex。判断依据很简单：需要遍历多张对象的记录、需要调用外部REST接口做应答处理、需要在一次事务里对超过一层父级关系做级联操作，这些场景用代码写出错率反而更低。比如要读取某账号下所有联系人的最新动态，再回写一个汇总字段到账号记录，Flow可以做到但要用循环，循环里再嵌套多对象查询，效率很低；这时候用Apex写个批处理类，半小时搞定且运行记录清晰。
在项目里我给团队定的标准是：“能用配置完成的不写代码；配置超过3个要素的用Apex。”第二种情况超过3个要素不代表配置做不了，而是维护成本高。Apex的缺点是平台会在执行时间上有限制，每次事务最多10秒，超过就会被强制终止。批量任务要写成Batchable接口，分包处理，这是初学者常忽视的。
5. 避坑指南：轻量级使用中最常见的四类翻车现场
5.1 导入数据时字段归属写错，全团队数据乱套
现象：通过Data Loader导入客户数据后，销售们发现自己的“我的客户”里看不到这些客户，但公共组里能看到，打开记录一看Owner是一个陌生账号。
原因：CSV里没有指定Owner字段，Data Loader默认把Owner分配给了执行导入的系统用户。
解决：在待导入CSV中增加一列OwnerId，填入用户别名（Alias）或用户Id。用别名最稳妥，因为Id在不同环境会变。导入前先在Data Loader的设置里点“生成登录日志”，确认使用正确的账号登录。再补一个习惯：导入后用SOQL检查一次每条记录的所有者是否正确，代码和上面2.3一样，只是把查询对象换成Account并加上OwnerId字段。
5.2 给所有人开了“全部可见”，权限管理形同虚设
现象：上线初期为了图省事，把几乎所有对象的OWD设为“公开读写”，不久后业务部门投诉“别人的客户都能看到，销售撞单严重”。
原因：业务数据通常需要私有或公开只读，公开读写让所有Profile里拥有该对象“查看”权限的用户都能修改其他人的记录。
解决：按对象重新梳理OWD。客户、商机、合同这类销售核心对象建议设为私有，然后通过共享规则分配可见范围。如果业务上要求所有人都能看但不能改，把OWD设为“公开只读”。这一步做完后回到3.3的检查清单逐条验证。
5.3 自动化规则互相触发，记录一改全表跟着改
现象：Process Builder更新某条商机时，触发了另一个Flow，第二个Flow又更新了同一条商机，于是第一个Flow再次被触发，最终出现多条运行日志并且记录字段被循环覆盖。
原因：流程A更新了触发条件依赖的字段，或者更新了同一条记录但没做“触发条件是否已改变”的判断。
解决：所有更新记录的自动化元素，都加一个执行条件判断，例如“只有当阶段不等于已审批时才执行更新”。在Flow的“决策”元素里把这个判断放在更新之前，能有效打断循环。另一个可靠手段是在Flow的启动条件里设置为“刚创建时”或“记录被创建或字段满足条件时”，避免“任何时间只要记录被更新”这种宽泛触发，可以大幅度降低循环概率。
5.4 Sandbox里数据一切正常，部署到生产环境后按钮、视图全不一样
现象：在Sandbox里创建好的自定义按钮和列表视图，通过变更集部署到生产环境后，生产环境“找不到对象”。
原因：自定义对象在变更集里没有包含“对用户可见”的权限分配。Sandbox里开发人员权限较大，一键能看到的记录类型在生产环境里对应Profile还没分配权限。
解决：在部署之前，检查变更集中是否包含：
- 自定义对象的字段级安全配置，是否已勾选目标Profile；
- 记录类型值和可用记录类型勾选；
- 列表视图的共享范围是否为公开或指定群组；
- 流程的部署状态是否为“已部署”。
这个场景我遇到过三次，每次都是同一个原因：生产环境的Profile权限没跟上。上线前用无人值守方式检查一遍所有对象、字段、自动化项的“生效/未生效”状态，能省掉大量返工时间。
6. 数据导入与导出：从CSV到一套可信任的业务数据
6.1 Data Loader导入客户数据的标准流程
Data Loader是Salesforce提供的桌面端数据导入导出工具，适合百万行级别的操作。在线导入向导有40万行的限制，大批量用Data Loader更稳妥。导入流程分四步：先做CSV模板、再映射字段、再执行、最后核对结果。
先在Excel里组织好数据，统一使用UTF-8带BOM的编码保存为CSV，否则中文内容导入后会乱码。字段名与Salesforce API名称保持一致。给每个字段加一列ID用于幂等更新，重复执行时不产生重复数据。
第二步是配置字段映射。Data Loader会读取CSV的表头和Salesforce对象的字段列表，把CSV里的“姓名”匹配到Contact的LastName，“公司名”匹配到Account的Name。匹配关系需要逐列确认，这一步最容易出问题：Salesforce的必填字段比CSV多一个，需要在“默认值”里补上，例如把OwnerId默认设置为执行账号的ID。
第三步是执行。Data Loader提供了Insert和Upsert两种选项，推荐Upsert并指定外部ID字段，这样重复导入不会重复建记录。如果是第一次导入且没有外部ID，那么使用Insert更稳妥。
第四步是核对。运行完成后Data Loader会生成Success和Error两个CSV文件，不要只在界面看成功条数，把Error文件下载下来逐行看错误信息。最常见的错误是必填字段缺失或查找关系字段找不到匹配记录。
6.2 导出与备份：没有比这更可靠的后悔药
定期导出是每个Salesforce管理员都该养成的习惯。Data Loader的Export功能可以把对象数据导出为CSV，推荐做“全量导出”而不是“增量导出”，因为增量导出依赖系统修改时间字段，一旦有人把旧数据直接改掉了修改时间，增量就查不出来。全量导出频率建议每周一次，备份保留最近一个月的数据快照。
导出的内容不要只导客户和联系人，还要导出自定义对象的明细数据、字段历史跟踪记录、以及系统审计日志。这些数据在出问题时最有价值——可以精确回答“这个字段从什么时候变成这个值的”“谁在什么时候改过这条记录”。字段历史跟踪需要在对象配置里为关心字段打开开关，最大配置30个字段，把关键字段都勾上，日常排障速度能快很多。
6.3 上线巡检的习惯让我少走了很多弯路
有个习惯值得在团队里推广：每次部署上线前，固定跑一遍“权限与自动化可用性检查”，包括确认新对象能看到、新字段有权限、新流程处于激活状态、新导入的同一批数据重复执行不会产生重复记录。这个习惯帮我避免过一次返工：某次上线前把流程部署了但忘了改记录类型对应的Profile，上线当天业务同事能用表单创建记录但看不到流程按钮，排查了半小时才发现是Profile权限缺失。
另一个习惯是：把Data Loader导出的CSV文件在本地用Excel做一次脏数据检查，日期格式、数字单位、空值比例都在本地搞定，再进Salesforce。这么做可以先挡掉一批低级错误，也方便业务方反馈“这批数据本身就有问题”。
最后提一句，Salesforce的配置不是只管一次就完事，业务常变，几十个对象的权限和自动化终有一天会变得散乱。把系统当作一个持续维护的工程，每次改动都记录在案，遇到问题按“触发条件-运行日志-字段权限”这样一条线去排，你会发现问题没有想象中玄学。希望这篇使用手册能帮到你。
本文还有配套的精品资源，点击获取
