企业官网建设流程全解析

简介：《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 Security，FLS）是下一个常见盲区。入口在 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”。

为了不让你在菜单里迷路，我把典型的权限配置顺序和检查点整理成一个表，照着做基本不会乱。

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 转 Date；PRIORVALUE() 取更新前的旧值，这个只有 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) DESC

GROUP BY 这里和 SQL 很接近，但要注意：一旦用了 GROUP BY，SELECT 里只能出现分组字段和聚合函数，其他字段一律不允许。否则系统会直接给出编译错误，你以为是自己语法错了，实际是 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。控制台里我一般这样写：

List<Account> accounts = [SELECT Id, Name FROM Account WHERE IsActive__c = FALSE LIMIT 10000]; List<Account> toUpdate = new List<Account>(); 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 App：Setup → App Manager → New Connected App，启用“Enable OAuth Settings”，选 “Password Flow”。拿到 Consumer Key 和 Consumer Secret 后，用 curl 换取 Token：

curl -X POST https://login.salesforce.com/services/oauth2/token \ -d "grant_type=password" \ -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?q=SELECT+Id,+Name+FROM+Account+LIMIT+100"

q 参数需要做 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(since=last_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 时心里都有一张地图，不会走两步就迷路。希望这套从手册到落地的路径能帮到你。

本文还有配套的精品资源，点击获取