简介《salesforce使用手册.pdf》是一份面向CRM初学者、销售运营人员及系统管理员的PDF版实用手册聚焦salesforce.com平台的核心概念与日常操作旨在解决后台配置不熟悉、权限与安全规则难以下手等问题。资源包仅含1个PDF文件大小约1.32MB体积虽小但内容结构完整基于salesforce.com用户手册整理涵盖平台概述、入门指引、组织设置、工具与实用程序、自定义界面等核心模块。手册重点展开系统管理相关内容包括设置组织信息、客户支持配置、组织简档、多币种管理、用户添加与角色划分、权限简档控制、登录限制、共享模式与自动共享规则、口令策略、会话安全性、用户事件监控、资源监控以及商机分配与升级规则等并延伸到队列、工作时间、Web个案与自助服务设置。同时还介绍帐户、联系人、商机、市场活动、业务机会、预测、个案与解决方案等CRM核心对象的使用逻辑并包含转移记录、批量删除数据等实用工具说明适合用于快速上手后台配置和日常查阅。该资源已有3205人学习是系统了解Salesforce基础运维与业务配置的不错选择。1. 从“打开手册就犯晕”说起salesforce使用手册.pdf 到底在解决什么问题很多同学第一次接手某公司的 Salesforce 租户时拿到手的是一份几百页的 salesforce使用手册.pdf。翻到目录的时候就先懵了Company Settings、Profile、Permission Set、Object Manager、Flow、Report每个词都认识连在一起不知道先动哪个。更常见的情况是你已经登录进了后台对着界面点了一圈结果只是把别人的配置看了一遍回头老板问你“这个字段为什么看不到”你仍然答不上来。这份使用手册真正要解决的不是“教你点按钮”而是帮你把业务问题翻译成配置动作谁能看到什么数据、哪些字段参与计算、数据保存前要满足什么规则、报表口径怎么和业务对齐。它适合两类人一类是刚接手某公司 Salesforce 维护的新手另一类是准备自己做自定义实施的技术负责人。本文不打算复述 PDF 里的每一个菜单而是按最常见的落地路径把权限、对象、公式、报表、自动化、对外接口这六块讲清楚并且把参数怎么设、坑在哪一并写出来。2. 把租户结构先钉在墙上Company、对象、字段与权限的配置顺序Salesforce 是一个多租户平台你登录后所在的“组织”就是一个独立的租户空间。很多新人把这个空间当成一个普通的数据库上来就建字段、传数据结果后面权限全乱。我一般会建议先做完权限结构再动数据和自动化顺序错了后面全是返工。2.1 Profile 与 Permission Set先分清“角色底座”和“叠加授权”在配置权限之前先想清楚一句话Profile 是角色底座Permission Set 是临时叠加授权。底座管的是“这拨人默认能干什么”叠加授权管的是“少数人额外能干什么”。常见的误区是想用 Profile 解决一切权限于是每来一个新需求就复制一个 Profile最后系统里有几十个 Profile连管理员自己都分不清哪个对应哪拨人。实际操作时建议这样做先按岗位建好少量 Profile比如“销售代表”“销售经理”“财务专员”“系统管理员”每个 Profile 只配对象级权限增删改查。然后当某个临时项目需要让一小部分销售看到额外对象时创建一个 Permission Set 挂上去而不是去改 Profile。这样底座保持稳定叠加授权可回收。这里有一个关键参数需要留意。Profile 里每个对象有五个权限位Read、Create、Edit、Delete以及两个超级权限 View All、Modify All。对普通业务对象正常给前四个就够了View All 和 Modify All 会绕过共享规则让用户看到该对象下所有记录属于管理员级别授权不要随手打开。如果只是某几个字段需要开放不要碰对象级权限去调整字段级安全。字段级安全Field-Level SecurityFLS是下一个常见盲区。入口在 Setup → Object Manager → 选择对象 → Fields Relationships → 找到字段 → Field Accessibility。这里的逻辑是即使你在 Profile 里给了对象 Read 权限只要字段级安全里没勾选用户在这个对象的页面、报表、搜索、API 查询里都看不到该字段。所以排查“字段看不到”时先看 FLS再看页面布局。我见过的最典型场景是这样的A同学给某公司做了一个“机会预计成交日期”的自定义字段数据库里数据已经导入成功但销售团队怎么都看不到管理层甚至怀疑导入失败。查到最后就是这个字段在 FLS 里没有给销售 Profile 开放。字段级安全的检查表建议按“对象 → Profile → FLS → 页面布局”的顺序走完少了任何一环数据就是“黑匣子”。2.2 对象、记录类型与共享规则的下钻设置对象Object相当于数据库里的表但它比表更重因为它自带权限、布局、验证规则和流程。标准对象是平台自带的比如 Account、Contact、Opportunity、Case。自定义对象一般以 __c 结尾比如 Project__c、Rebate__c。在开始建模之前先确认一件事能不能用标准对象上面的字段扩展还是必须新建自定义对象。能用标准对象就用标准对象因为报表、列表视图、全局搜索都是优先支持标准对象的自定义对象在建报表时要多走几步。Record Type记录类型是我建议尽早理解的概念。它让同一个对象在不同的业务线里有不同的字段布局和下拉选项。例如同一个“订单”对象线上渠道和线下渠道的销售流程不同阶段选项也不同。配置 Record Type 时系统会要你指定默认 Record Type还要在 Profile 中把对应的 Record Type 设为可见。这里有个容易忽略的点如果某个 Profile 下没有勾选任何 Record Type新建记录时会直接报错提示“The record is not accessible in this Record Type”新人经常以为是自己页面坏了。共享规则Sharing Rule负责的是“行级”可见性。Salesforce 默认有一种共享模型叫 Private即用户只能看到自己拥有或有权限的记录。如果你发现用户登录后看不到同事的客户而对象级权限又没有问题多半是这里没有配。常见做法是配置 Public Groups把销售团队加进组再基于该组建 Sharing Rule共享规则的粒度是对象条件是筛选器比如“Owner 等于某个组的成员”动作是“Read Only”或“Read/Write”。为了不让你在菜单里迷路我把典型的权限配置顺序和检查点整理成一个表照着做基本不会乱。步骤入口要设置的内容常见失误1. 建 ProfileSetup → Users → Profiles对象级权限、Record Type 可见性随手勾 View All2. 建 Permission SetSetup → Users → Permission Sets叠加对象/字段权限用它做底座3. 配 FLSObject Manager → 字段 → Field Accessibility勾选字段可见/可编辑只改 Profile 不改 FLS4. 配 Record TypeObject Manager → Record Types布局、选项列表遗漏默认类型5. 配共享规则Setup → Sharing SettingsPublic Groups Sharing Rules忘记开 Private 模型6. 验证用测试用户模拟登录以指定身份查看数据只看管理员视角3. 业务规则落地的两把钳子公式字段与 Validation Rule 的参数化写法权限和对象结构定下来之后下一步就是把业务规则落到系统里。Salesforce 上最常见的两把钳子是公式字段Formula Field和验证规则Validation Rule。前者是“存引用逻辑结果”后者是“保存前拦一道”。很多新手把这两者混为一谈公式字段想着拦截验证规则想着算值结果两边都长得四不像。3.1 公式字段从空值判断到跨对象引用公式字段在保存时自动计算只读不占数据库物理存储。它的返回值类型主要有 Boolean、Number、Date、Text 这几种。创建入口是 Object Manager → 选择对象 → Fields Relationships → New → Formula。公式语法的思维方式比较接近 Excel但有几个明显差异布尔判断用 而不是 字符串用单引号引用字段用 API 名称好多新人栽在双引号上。一个最常用的场景是“计算商机金额下浮后的预计收入”公式可以这么写IF( 行级安全有效期, AND(IsClosed FALSE, ISBLANK(CloseDate)), ... )上面这段是我故意演示的“反例”为了说明一件事公式字段里不要写得太复杂复杂逻辑优先交给 Flow。真正能落地的写法会简单得多。比如计算“已关闭商机从关闭到今天的时长天”IF( IsClosed TRUE, TODAY() - CloseDate, NULL )CloseDate 是标准字段TODAY() 返回当前日期两者相减得到的是整数天数。如果 CloseDate 为空则 TODAY() - CloseDate 会返回 null不会报错但整个字段也变成空白。所以当我需要把空白和真正的 0 区分开来时会额外包一层 ISBLANK 判断而不是只靠减法。跨对象引用是公式字段里最容易迷路的地方。比如我想展示关联客户的地区写Account.Region__c当这个公式定义在 Opportunity 对象上时Account.Region__c 是通过“Opportunity → 关联的 Account → Region__c 字段”取过来的这就是常见的“点号路径”。跨对象引用最多可以跨五级关系但我建议最多跨到两级再多既难维护又在报表里难以排查。公式字段不想显示在 API 查询、列表视图和报表里时同样要回 FLS 设置可见性因为公式字段本质上还是一个字段。你把它写成公式不代表所有有对象读权限的人都能看到它。常用函数里除了 IF、ISBLANK、TODAY()还要留意这几个TEXT() 把数字转字符方便拼接DATEVALUE() 把 DateTime 转 DatePRIORVALUE() 取更新前的旧值这个只有 Validation Rule 和流程公式里能用普通公式字段不提供。每次写完公式先点一下“Check Syntax”系统会直接告诉你是函数拼错还是字段 API 名称不对这一步能省掉一半的报错时间。3.2 Validation Rule保存前拦截的那一行错误消息验证规则的作用是在记录保存之前检查条件条件不满足就直接拒绝保存同时弹出错误消息。它比页面按钮置灰更可靠因为验证规则在 API、导入、Flow 创建记录时也会执行也就是说不管数据从哪来规则都生效。举例当商机已关闭但关闭原因还是空就不允许保存AND( IsClosed TRUE, ISBLANK(ClosedReason__c) )注意 ClosedReason__c 是我假设的自定义字段标准字段的 API 名称是 StageName、CloseDate 之类的。验证规则里通常要放两个输入错误条件满足就报错和错误消息。错误消息支持合并字段可以写“请先填写{!ClosedReason__c}再关闭”。这块有个很实用的点错误消息在页面上提示给用户时会落在记录顶部或指定字段下方建议把“错误字段”选成真正缺失的那个字段而不是默认的“Top of Page”。不然用户看到顶部一排红字还不知道要改哪个。还有一个高频坑是“更新场景下用旧值”。验证规则默认读取的是新值PRIORVALUE() 用于读更新前的值。比如“订单总金额变少了必须填写审批备注”写成AND( PRIORVALUE(TotalAmount__c) TotalAmount__c, ISBLANK(ApprovalNote__c) )这样只有当“旧金额大于新金额”时才拦截。如果不用 PRIORVALUE每次编辑都会触发哪怕你没有改金额规则也会因为总金额本身非空而通过但在需要比较新旧值的场景里不用 PRIORVALUE 就彻底失效。参数层面还要注意验证规则的“启用”开关。新建时默认启用但如果某一批次历史数据导入时想临时放宽校验可以把它停用导入完再启。这个操作流畅但一定要记得再打开否则后患无穷。验证规则的优先级问题多条规则之间是 AND 关系系统不保证顺序只要命中任意一条就拒绝保存所以不要把两条互斥的规则写进去。到这里业务规则的两把钳子已经说清楚了。公式字段负责算验证规则负责拦两者都不要碰复杂分支流程分支逻辑请交给下一章的 Flow 或 Process Builder——如果你还在用旧组件的话。4. 用 SOQL 和报表把数据带出场字段名规则、筛选条件与导出边界配置做完之后数据就要开始“出场”了。出场有两条路一条是入报表和仪表盘给业务看另一条是走 API给外部系统拉。两者底层都绕不开查询语言。Salesforce 的查询语言叫 SOQL长得像 SQL但脾气完全不同。4.1 SOQL 与 SQL 的明显差异关系查询、__c 后缀与权限裁剪SOQL 不允许 SELECT *必须列出每个字段名。更麻烦的是它不支持表关联 JOIN表之间通过主从关系用点号取关联字段。举例查所有联系人以及他们所属的客户名称和客户区域SELECT Id, Name, Account.Name, Account.Region__c FROM Contact WHERE Account.Region__c 北方区 LIMIT 200这里的 Account.Name 就是走关系路径取客户名称不是 JOIN。如果联系人的 AccountId 为空这行记录的 Account.Name 也返回 null查询不会报错。还有两个细节自定义字段要带 __c联系人标准字段 Name 直接写筛选条件里字符串用单引号千万不要写成双引号这是最频繁的报错来源。再举一个分组统计的例子把商机按来源统计数量和金额合计SELECT LeadSource, COUNT(Id), SUM(Amount) FROM Opportunity GROUP BY LeadSource ORDER BY COUNT(Id) DESCGROUP BY 这里和 SQL 很接近但要注意一旦用了 GROUP BYSELECT 里只能出现分组字段和聚合函数其他字段一律不允许。否则系统会直接给出编译错误你以为是自己语法错了实际是 SELECT 里多了字段。还有一个权限裁剪点SOQL 查询默认受“用户级权限”约束。也就是说用户用 API 查询时返回的数据行会先经过共享规则和字段级安全裁剪。如果某用户看不到某个字段SOQL 里查这个字段会直接报错“No such column”而不是返回空值。排查时先确认是不是 FLS 问题不然你会在报表和代码两个地方来回折腾。SOQL 的 LIMIT 最多支持 50000 行如果返回更多系统会抛个异常。我一般会先敲 COUNT(Id) 看总量再分页取数。分页用 OFFSET 或游标OFFSET 到 2000 之后性能明显下降大批量别用它。这里的技巧是先用 ORDER BY 定序再按主键区间分批比如 WHERE Id 上一个查询拿到的最大 Id配合 ORDER BY Id 使用。效果比 OFFSET 稳定得多。4.2 报表与仪表盘从行筛选到图表口径配置报表时很多人一上来就选“报表类型”然后发现可选对象和筛选器都不全。原因是 Salesforce 报表是基于“报表类型”来组织对象的标准报表类型可能没覆盖你的业务需需要新建自定义报表类型。入口在 Setup → Report Types里面选定主对象和关联对象再决定是“只显示匹配记录”还是“所有记录”。报表类型选好后实际构建报表的字段分三类维度行、列、值。销售看板常用漏斗图展示阶段分布那就把 StageName 放行Amount 放值。这里的参数有一个很容易被忽略汇总字段的“记录数”。默认显示记录总数但如果你勾了“Summarize”里的特殊功能行数会和明细记录数对不上导致图表总数看上去少了。报表和仪表盘的另一个“玄学”点是筛选器作用域。报表里的日期筛选器如果选“当前财年”它跟“按创建日期为当前自然年”是不一样的财年是在公司信息里配置的。两个口径混用月度趋势就会在年初出现断崖业务部门会找你麻烦。我一般会在报表标题里直接写明口径比如“按关闭日期-当前财年-北方区”避免后面扯皮。报表下方可以导出 CSV、XLSX 或者完整 PDF但导出行数超过 2000 行的时页面会提示你需要启用“增强导出”增强导出量最大数十万行。不要点完导出就关闭浏览器系统是异步生成文件文件生成好会发送到你的邮箱或“我的下载”区域。如果你发现导出的 CSV 在 Excel 里中文乱码那是因为文件编码不是 UTF-8 with BOM临时处理方法是先用记事本打开再另存为 UTF-8或者用查询工具直接走 API 取数。5. 权限与自动化流程的避坑清单5 个高频翻车现场与修复路径做 Salesforce 实施最大的痛苦不是做不出来而是做出来之后上线一用就翻车。下面这 5 个坑是我见过和踩过的高频现场按“现象 → 原因 → 解决”写清楚建议保存下来当作排查手册用。5.1 用户登录后天天问你“我的客户为什么只剩几条”这个现象十有八九出在共享模型上。现象是某用户前几天还能看到全公司客户今天突然只剩下自己名下的记录连经理都看不到下属的客户。原因组织默认共享模型被人改成了 Private或者某次配置 Sharing Rule 时误删了原来的 Public Group。解决去 Setup → Sharing Settings 看默认共享模型再从“共享规则”里看 Public Group 是否还在。如果规则在但不起作用检查规则筛选条件里的对象很多时候是条件写成了 Account Owner 等于当前用户而不是等于组导致只对本人生效。修复后还要让用户重新登录刷新权限缓存不然他可能还是看成旧数据。5.2 公式字段全是空白数据却有值这个坑最迷惑人。现象管理员在记录详情页能看到公式结果但同事说字段空白或者字段在报表里显示为空白打开记录看又有值。原因一FLS 没勾选这个前面已经说过。原因二公式里包含空值任何一个输入字段为空公式结果就为空比如用“客户名称 商机编号”拼单号客户没填时整个字段就空。解决把 ISBLANK 判断包在公式里用 IF 分支返回字符串“待补充”这样字段至少不是空白。注意公式里空字符串和 null 是两回事有时看起来为空实际是“空字符串”ISBLANK 对空字符串返回 FALSE需要再用 ISNULL 做二次判断。5.3 保存 Flow 之后只对“新记录”生效修改记录没反应现象你建了一个记录触发的 Flow想实现在关单时自动抄送邮件。测试时新建商机生效把已有商机改成“已关闭”却没反应。原因Flow 的触发类型没有覆盖“记录更新”。记录触发式 Flow 有三种触发类型创建时、更新时、创建或更新时。如果选成“创建时”更新自然不会触发。解决在 Flow 的 Start 元素里把触发方式改成“Created Updated”再设置条件“仅当 StageName 变更为已关闭时才继续”。这里还有个细节Flow 运行时会校验你是否有权限修改该字段如果没有Flow 会静默跳过表现为“什么都不发生”。遇到这类情况时去 Setup → Debug 里打开 Flow 的调试日志看失败节点提示。5.4 报表数字和明细表对不上少了一大截现象某月销售额报表显示 100 万但导出的明细求和是 120 万。原因报表默认有“行级安全”限制另外报表筛选器里可能设置了“仅显示我作为成员的团队”之类的条件而明细导出是绕过报表汇总直接取数。解决先在报表的筛选器面板看是否所有筛选器都有“无”选项然后检查报表类型把关联对象限定成了“仅内部可访问”导致部分子记录被剪掉。最有效的排查方法是建一个不带任何筛选条件的明细报表和汇总报表做差集快速定位是哪一维被裁剪了。若两者始终一致再考虑是不是团队字段导致的。5.5 大批量更新数据时页面卡死操作直接失败现象在开发者控制台用一条 SOQL 取出 4 万条记录然后批量更新系统提示受限制、超时或 500 错误。原因单条 DML 批量处理 10000 条以上或者执行上下文内循环内再查询数据库都会触发 CPU 时间限制或 DML 行数限制。解决分批处理一次 200 条加一个钟点计划任务或者改用 Bulk API 2.0。控制台里我一般这样写ListAccount accounts [SELECT Id, Name FROM Account WHERE IsActive__c FALSE LIMIT 10000]; ListAccount toUpdate new ListAccount(); for (Integer i 0; i accounts.size(); i) { accounts[i].IsActive__c TRUE; toUpdate.add(accounts[i]); if (Math.mod(toUpdate.size(), 200) 0 || i accounts.size() - 1) { update toUpdate; toUpdate.clear(); } }每次 200 条批量提交避免一次性 DML 触碰上限。使用开发者控制台执行时还要注意“匿名 Apex”有 60 秒超时数据量再大就开 Bulk API 或放 Queueable 里跑。记住一条原则批量数据操作不走界面手工点码一套可重跑的逻辑最稳。6. 接出数据与做增量同步两个从手册走向落地的验证习惯配置做得再漂亮最终要回答老板一句话“我们的数据能不能和别的系统互通”这里给你两个实际可落地的方向用 REST API 把数据交给外部系统以及用外部 ID 做幂等更新。这俩也是我在每份使用手册里一定会圈出来的重点。6.1 用 REST API 把数据交到外部系统Salesforce 对外提供 REST API常见做法是先建立一个 Connected App再通过 OAuth 2.0 拿 Access Token。演示用密码流获取 Token先创建 Connected AppSetup → App Manager → New Connected App启用“Enable OAuth Settings”选 “Password Flow”。拿到 Consumer Key 和 Consumer Secret 后用 curl 换取 Tokencurl -X POST https://login.salesforce.com/services/oauth2/token \ -d grant_typepassword \ -d client_id你的ConsumerKey \ -d client_secret你的ConsumerSecret \ -d username你的登录邮箱 \ -d password你的密码安全令牌返回 JSON 里的 access_token 就是要用的凭证。注意 password 参数必须是“登录密码 安全令牌”拼接安全令牌在哪里拿登录后点右上角头像 → Settings → Reset My Security Token系统会发到邮箱。拿到 Token 就能查询数据curl -H Authorization: Bearer 你的access_token \ https://你的实例域名.salesforce.com/services/data/v版本号/query?qSELECTId,NameFROMAccountLIMIT100q 参数需要做 URL 编码 号可以替代空格。实例域名一般在登录后浏览器的地址栏里能看到形如 myCompany 开头的一串不要把 login.salesforce.com 直接拿来当查询入口那里只负责鉴权。版本号不要凭记忆写去 Setup 里搜 API会显示当前环境可用的版本号稳定优先选上一个稳定版而不是最新版避免你在生产环境撞上刚发布未收敛的接口行为。6.2 增量同步与幂等更新用外部 ID 做后悔药同步数据时我强烈建议别用“先删后插”的策略除非有明确诉求。比较稳的做法是把外部系统的业务主键放在一个外部 ID 字段上比如 External_Id__c然后把 External_Id__c 标记为“外部 ID”类型这样就能用 upsert 操作。upsert 的含义是有则更新无则插入。代码里的写法类似# 伪代码示意逻辑 records external_api.get_updated_records(sincelast_run_time) for rec in records: sf_data { External_Id__c: rec[id], Name: rec[name], Region__c: rec[region] } sf.bulk.Account.upsert(sf_data, External_Id__c)这里的参数 External_Id__c 是数据键如果系统里已有该 ID 的记录它会执行更新而不是新建一条重复记录。增量同步的时间边界建议用 LastModifiedDate而不是 CreatedDate因为编辑过的记录也需要同步。但注意 LastModifiedDate 是 GMT 时间外部系统要用 UTC 来对齐避免差 8 小时导致漏同步。验证同步是否正确的习惯也很重要。我每周会跑一次双向对账取外部系统记录数和服务器的记录数按 External_Id__c 求差集把差异清单拉出来看。不等到业务投诉再说“数据不同步”而是让问题暴露在自查阶段。关于幂等更新还有一个隐藏后悔药在同步前把记录快照写进一个存档对象一旦发现同步规则出错可以快速还原历史值而不是靠人工捡数据。这两个习惯做完你会发现自己从“照着手册点按钮”的角色慢慢变成了“按业务逻辑设计数据流”的角色。配置界面只是前台接口和同步才是把 Salesforce 融入企业系统的关键通道。我个人的习惯是每接管一个新租户先画一张“对象关系 权限矩阵 同步链路图”再碰任何配置这样后续做公式、报表、Flow 时心里都有一张地图不会走两步就迷路。希望这套从手册到落地的路径能帮到你。本文还有配套的精品资源点击获取