Lesson 3: Change Management

1

第 63 页

今天我们来聊聊Salesforce中的“变更管理”。听起来可能有点技术性，但其实很简单，就像你在家里重新布置家具一样，需要有计划、有步骤地进行。首先，什么是变更管理呢？在Salesforce中，变更管理指的是对系统进行修改或更新的过程。这可能是添加新的功能、修改现有的设置，或者修复一些问题。就像你家里的电器需要定期维护一样，Salesforce系统也需要不断地更新和改进，以保持其高效运行。那么，为什么需要变更管理呢？想象一下，如果你在家里随意移动家具，可能会导致空间混乱，甚至可能损坏家具。同样，在Salesforce中，如果没有一个明确的变更管理流程，随意的修改可能会导致系统不稳定，数据丢失，或者影响用户体验。 Salesforce的变更管理通常包括以下几个步骤： 1. ，需求收集，：首先，我们需要明确为什么要进行变更。这可能是来自用户的反馈，或者是业务发展的需要。就像你决定重新布置房间是因为需要更多的储物空间一样。 2. ，计划制定，：接下来，我们需要制定一个详细的计划，包括变更的内容、时间表、以及可能影响的范围。这就像你在重新布置房间前，会画一个草图，规划每件家具的位置。 3. ，测试，：在正式实施变更之前，我们需要在测试环境中进行充分的测试，确保一切按预期工作。这就像你在移动家具前，会先试放一下，看看是否合适。 4. ，实施，：如果测试没有问题，我们就可以在正式环境中实施变更了。这就像你最终按照计划，把家具移动到新的位置。 5. ，监控和反馈，：变更实施后，我们需要持续监控系统的表现，并收集用户的反馈。这就像你重新布置房间后，会观察一段时间，看看是否真的方便了生活。通过这样的流程，我们可以确保Salesforce系统的每一次变更都是安全、有效的，就像你精心布置的家一样，既美观又实用。好了，这就是今天的课程内容。希望你们对Salesforce的变更管理有了更清晰的理解。下次课我们将继续探讨更多有趣的内容。记得，每一次变更都是一次进步的机会，只要我们谨慎行事，就能让系统更好地服务于我们的业务需求。

查看详情

2

Change Management Process

第 64 页

让我们来聊聊Salesforce中的更改管理流程。这个过程其实就像是在建造一座房子，我们需要确保每一步都做得稳稳当当，才能保证最后房子的安全和舒适。首先，我们得了解不同类型的沙盒。沙盒就像是我们的建筑工地，有几种不同的类型：开发沙盒、部分复制沙盒和全复制沙盒。每种沙盒都有它的特点，比如开发沙盒适合做小规模的测试，而全复制沙盒则更像是一个完整的复制品，适合做全面的测试。选择哪种沙盒，取决于你需要测试的规模和深度。接下来，我们得在沙盒里配置和测试我们的更改。这就像是在工地上搭建模型，看看设计是否合理，结构是否稳固。我们需要确保所有的更改都能正常工作，不会影响到现有的系统。然后，我们需要把在沙盒中测试好的更改移动到生产环境。这个过程就像是把模型从工地搬到实际的建筑地点。在Salesforce中，我们通常使用变更集来完成这个任务。变更集就像是一个搬运工具，它可以帮助我们把更改从一个环境安全地移动到另一个环境。最后，我们需要确保所有的更改都已经正确地应用到了生产环境中，并且没有引起任何问题。这就像是在建筑完成后，我们需要做一次全面的检查，确保一切都按照计划进行。总之，更改管理流程是一个需要细心和耐心的过程，但只要我们按照步骤来，就能确保我们的Salesforce环境既安全又高效。

查看详情

3

Change Management Process for AW Computing

第 65 页

让我们来聊聊AW Computing的变更管理流程。这个流程主要是为了确保我们在Salesforce上做的任何改动都是经过深思熟虑的，不会影响到日常的业务运作。首先，当有新的需求或者需要改进的地方时，管理员会参与进来。他们的角色非常重要，因为他们需要向核心团队提供专业的意见和建议，帮助团队找到最佳的解决方案。这就像是你在装修房子之前，会咨询设计师的意见一样，确保每一步都走得稳妥。接下来，管理员会在沙箱环境中配置和测试这个解决方案。沙箱就像是Salesforce的一个“试验场”，在这里，我们可以安全地尝试各种改动，而不用担心影响到实际的生产环境。这一步非常关键，因为它能帮助我们提前发现并解决问题，确保一切都能按预期工作。最后，一旦解决方案在沙箱中测试无误，管理员就会负责将这个改动部署到生产环境中。生产环境就是我们实际使用的Salesforce系统，所有的改动都会在这里生效。这一步需要非常小心，因为一旦部署，改动就会影响到所有用户。总的来说，这个流程确保了每一次的改动都是经过严格测试和验证的，最大限度地减少了出错的可能性，保证了系统的稳定性和安全性。希望这个解释能帮助你更好地理解AW Computing的变更管理流程！

查看详情

4

Lesson Agenda

第 66 页

今天我们来聊聊Salesforce中的两个重要概念：课程日历管理沙盒中的更改，以及如何使用变更集来部署这些更改。首先，我们来说说“课程日历管理沙盒中的更改”。在Salesforce中，沙盒（Sandbox）是一个独立的环境，它复制了你的生产环境，但允许你在不影响实际业务的情况下进行测试和开发。想象一下，沙盒就像是一个安全的实验场地，你可以在这里尝试新的功能、修改设置，或者测试新的业务流程，而不用担心会影响到你的实际业务数据。当你在这个沙盒环境中对课程日历管理进行更改时，比如添加新的课程、调整时间表或者修改课程内容，这些更改都只会在沙盒中生效。这样，你就可以在不影响实际用户的情况下，确保所有的更改都是正确和有效的。接下来，我们谈谈“使用变更集部署变更”。当你完成了在沙盒中的测试，并且确认所有的更改都符合预期，下一步就是将这些更改部署到生产环境中。这时，变更集（Change Set）就派上用场了。变更集是一个包含了你想要部署的所有更改的集合。你可以把它想象成一个包裹，里面装着你从沙盒中精心挑选的更改。通过变更集，你可以将这些更改安全、有序地传输到生产环境中。部署变更集的过程非常简单。首先，你需要在沙盒中创建一个变更集，并将你想要部署的更改添加到这个变更集中。然后，你可以将这个变更集上传到生产环境。在生产环境中，管理员会审查这些更改，并决定是否批准部署。一旦批准，这些更改就会应用到生产环境中，从而影响到实际的业务操作。总结一下，沙盒提供了一个安全的环境，让你可以自由地进行测试和开发，而变更集则是一个强大的工具，帮助你将这些更改安全地部署到生产环境中。通过这两个步骤，你可以确保所有的更改都是经过充分测试和验证的，从而减少在生产环境中出现问题的风险。希望这个解释能帮助你更好地理解Salesforce中的课程日历管理沙盒和变更集的使用。如果你有任何问题，随时欢迎提问！

查看详情

5

Configuring Changes in a Sandbox

第 67 页

同学们，今天我们来聊聊在Salesforce沙箱中配置更改的一些关键点。首先，我们会登录到制作组织，也就是我们的主要工作环境。在这里，我会向大家展示一个案例，叫做“应收账款需要跟踪Salesforce中的客户计费问题”。这个案例帮助我们理解如何在Salesforce中处理客户的账单问题。接下来，我们会讨论一下在Salesforce中提交请求的两种方式：通过案例和通过Chatter Post。你们可能会问，这两种方式有什么区别呢？哪种方式更适合使用？或者，我们是否可以同时使用这两种方式？这些都是很好的问题，我们会一起探讨。然后，我会带大家看看批准历史记录。在这里，你们会看到Noah已经批准了这个请求。这显示了请求的审批流程，是Salesforce中一个重要的功能。最后，我们会查看“要求”字段。在之前的模块中，你们已经审查了这些要求，并提出了如何设计解决方案来满足这些要求的建议。现在，我们会看到“提议的解决方案”字段，这里记录了核心小组审查后的最终解决方案。通过这些步骤，你们将更深入地理解如何在Salesforce沙箱中配置和管理更改，以及如何有效地使用Salesforce的功能来解决问题。希望这些内容对你们有所帮助！

查看详情

6

What is a Sandbox?

第 68 页

大家好，今天我们来聊聊Salesforce中的一个非常实用的功能——沙盒。想象一下，沙盒就像是一个安全的实验场地，你可以在里面尝试各种新想法和操作，而不用担心会影响到你实际使用的Salesforce生产环境。这是因为沙盒和生产环境是完全隔离的。当你想要测试新的自定义设置或者应用更新时，你需要创建一个新的沙盒或者刷新现有的沙盒。这样，你就可以看到自上次操作以来，你的Salesforce组织有哪些新的变化。而且，任何在沙盒中做出的更改，都需要手动部署到生产环境中，确保一切都在控制之中。有趣的是，沙盒在每次Salesforce发布新功能前大约2到3周就会更新。这意味着你可以提前预览新功能，决定是否要在生产环境中使用它们。当然，你也可以选择不这么做。最近，Salesforce还推出了一个新功能，叫做“新春20”。现在，你可以克隆一个与生产环境不同版本的沙盒。这在以前是不可能的，因为如果沙盒和生产环境的版本不同，克隆功能就会被禁用。但现在，你可以使用这个功能来进行开发、测试和培训。此外，Salesforce还引入了数据掩码功能，这是一个强大的数据安全工具。管理员可以使用数据掩码自动屏蔽沙盒中的数据，而不是手动去保护这些数据。最后，Salesforce还增加了一个新的权限——“管理沙盒”。这个权限允许用户创建、刷新、激活和删除沙盒，而不需要授予他们“修改所有数据”的权限。这样，你就可以让用户管理沙盒，同时保持对数据安全和访问控制的完全掌控。希望这些信息对你们有所帮助，如果你们有任何问题，随时欢迎提问！

查看详情

7

Creating or Refreshing a Sandbox

第 69 页

大家好，今天我们来聊聊Salesforce中的沙箱创建和刷新。沙箱，简单来说，就是一个复制了生产环境的测试环境。当你创建或刷新沙箱时，生产环境中的元数据会被复制到沙箱中。那么，什么是元数据呢？元数据就像是描述应用程序中数据的数据，它包含了应用程序的外观、感觉以及功能的信息。具体来说，元数据包括但不限于以下几个方面： - 领域：定义了应用程序的业务范围。 - 页面布局：决定了用户界面的布局方式。 - 记录类型：用于区分不同类型的记录。 - 配置文件：定义了用户的权限和设置。 - 权限集：进一步细化用户的权限。 - 报告和仪表板：用于数据分析和展示。 - 报告类型：定义了报告的结构和内容。 - 应用程序：包含了业务逻辑和流程。 - 对象：代表了业务中的实体，如客户、产品等。创建或刷新沙箱的过程，实际上是将这些元数据从生产环境复制到沙箱环境，以便在沙箱中进行开发、测试和培训。这样，你就可以在不影响生产环境的情况下，进行各种实验和学习。另外，有一个小技巧要告诉大家。你可以在不刷新沙箱的情况下，将生产环境中的许可证与沙箱组织进行匹配。具体操作是：登录到你的沙箱组织后，点击“设置”，然后选择“公司简介”下的“公司信息”，最后点击“匹配生产许可证”即可。希望今天的讲解对大家有所帮助，如果有任何疑问，欢迎随时提问。我们下次再见！

查看详情

8

Metadata Versus Data

第 70 页

今天我们来聊聊Salesforce中的两个重要概念：元数据和数据。这两个词听起来可能有点技术性，但其实它们的概念很简单。首先，我们来说说元数据。你可以把元数据想象成是一个蓝图或者是一个模板。它描述了Salesforce中对象的字段和结构。比如说，如果你有一个“客户”对象，元数据就会告诉你这个对象有哪些字段，比如“客户名称”、“地址”、“电话”等等。元数据就是这些字段的定义和它们之间的关系。接下来是数据。数据就是这些字段里实际填写的值。继续用“客户”对象来举例，如果“客户名称”这个字段里填写的是“张三的公司”，那么这个“张三的公司”就是数据。数据是具体的、实际的信息，而元数据则是这些信息的框架和规则。简单来说，元数据告诉你有什么样的信息可以填写，而数据则是你实际填写进去的信息。希望这个解释能帮助你更好地理解这两个概念。如果有任何问题，随时问我哦！

查看详情

9

Sandbox Types

第 71 页

今天我们来聊聊Salesforce中的沙盒类型。沙盒在Salesforce中是一个非常重要的工具，它可以帮助我们在不影响实际业务的情况下进行测试和开发。Salesforce提供了四种不同类型的沙箱：完整数据沙盒、部分数据沙盒、开发人员专业沙盒和开发人员沙盒。首先，完整数据沙盒和部分数据沙盒的主要区别在于它们支持的数据存储量以及数据是否与元数据一起复制。完整数据沙盒会复制生产环境中的所有数据和元数据，而部分数据沙盒则只会复制一部分数据，但同样会复制所有的元数据。接下来是开发人员专业沙盒和开发人员沙盒。这两种沙盒主要是为开发人员设计的，它们的数据存储量较小，适合进行代码开发和测试。开发人员专业沙盒可以复制一定量的数据和所有元数据，而开发人员沙盒则只复制元数据，不复制数据。最后，刷新沙箱是一个非常重要的操作。当你刷新沙箱时，它会重新初始化为生产组织的最新配置状态。这意味着所有的数据和元数据都会被更新到最新的状态，这对于确保测试环境与生产环境保持一致非常关键。希望这些信息能帮助你更好地理解和使用Salesforce中的沙盒。如果你有任何问题，随时可以问我！

查看详情

10

Sandbox Templates

第 72 页

今天我们来聊聊Salesforce中的沙盒模板。沙盒模板是一个非常实用的工具，它可以帮助我们更快地创建沙盒环境，同时还能保护我们的敏感数据不被泄露。首先，沙盒模板只能与完整或部分数据沙箱一起使用。这意味着，当你需要创建一个新的沙盒环境时，你可以选择使用沙盒模板来减少创建时间。沙盒模板允许你排除那些敏感的数据，这样你就可以创建一个只包含项目必要数据的沙盒环境，既安全又高效。当你将沙盒模板应用于部分数据沙盒时，Salesforce会从生产数据中抽取一个子集，并将其加载到沙盒组织中。这样做的好处是，你可以在更短的时间内获得一个丰富的数据集，这对于测试和开发来说是非常有帮助的。另外，沙盒模板还有一种使用方式，那就是克隆现有的沙盒，而不是直接从生产组织中复制数据。通过这种方式，你可以使用之前已经选择好的数据和元数据集来填充任何类型的沙箱，这无疑会大大节省你的时间。总的来说，沙盒模板是一个非常灵活且强大的工具，它可以帮助我们更高效地管理和使用沙盒环境。希望今天的讲解能帮助你更好地理解和使用沙盒模板。如果有任何问题，随时欢迎提问！

查看详情

11

Sandbox Management

第 73 页

今天我们来聊聊Salesforce中的沙盒管理。想象一下，沙盒就像是一个安全的实验场地，开发人员可以在这里自由地尝试新的代码和配置，而不用担心影响到实际的生产环境。首先，单个开发人员可以使用多个开发人员沙箱。这些沙箱非常适合用来编写代码、进行配置和测试。你可以把它们看作是你的个人实验室，在这里你可以尽情地实验和调整，直到一切运行得完美无缺。接下来是开发人员专业沙箱，或者我们也可以叫它部分数据沙箱。这种沙箱非常适合用来组合和测试代码，同时也可以用来测试配置的更改和培训用户。你可以在这里模拟真实的数据环境，但数据量会相对较小，这样既保证了测试的真实性，又不会占用太多的资源。最后，我们还有完整的沙箱。这种沙箱几乎复制了生产环境的所有数据和配置，非常适合用于用户接受测试和回归测试。在这里，你可以确保所有的更改都能在生产环境中顺利运行，而不会出现意外。在一个沙箱中进行的代码或配置更改，可以轻松地部署到另一个沙箱或直接部署到生产环境中。这样，你就可以确保每一步的更改都是经过充分测试和验证的，从而大大降低了生产环境中出现问题的风险。总之，沙盒是Salesforce开发中不可或缺的一部分，它提供了一个安全、可控的环境，让开发人员可以放心地进行创新和测试。希望今天的讲解能帮助你更好地理解和使用沙盒。如果有任何问题，随时欢迎提问！

查看详情

12

From the production organization:

第 74 页

让我们来聊聊Salesforce沙箱的一个小细节——用户名的变化。当你创建一个沙箱时，Salesforce会自动调整所有用户的用户名和电子邮件地址。这是怎么做到的呢？很简单，Salesforce会在你的生产环境用户名后面加上沙箱的名称。比如说，如果你的生产环境用户名是john.doe@example.com，而你的沙箱名称是“Test”，那么你在沙箱中的用户名就会变成john.doe@example.com.test。这样的设计有一个很好的理由：它允许用户使用他们熟悉的登录信息来访问沙箱，同时确保沙箱和生产环境的账户是分开的。这样，你就可以在沙箱中安全地进行测试或培训，而不用担心影响到生产环境的数据。所以，下次当你登录沙箱时，如果发现用户名有点不一样，不要惊讶，这只是Salesforce在帮你保持环境的整洁和安全。

查看详情

13

Goal: Configure billing cases for Accounts Receivable in a sandbox.

第 75 页

同学们，今天我们要学习如何在Salesforce沙箱环境中配置应收账款的开票案例。这个过程涉及到多个步骤，我会一步步带大家操作。首先，我们需要登录到生产环境的沙箱。登录后，我们要为知识文章创建一个新的文本区域字段，这个字段将用于存储文章的正文内容。创建好之后，我们需要在知识页面布局上调整这个新字段的位置，将它移动到URL名称的下方。接下来，我们要为案例对象创建一个新的文本字段，叫做“发票编号”。这个字段将用于记录每个案例的发票信息。然后，我们还需要创建一个新的字段，叫做“信用状态”，这个字段将用于查找账户的信用状态。注意，这个字段只对特定的用户组可见，包括应收账款用户、执行用户和系统管理员。之后，我们需要复制现有的案例页面布局，创建一个新的布局，叫做“账单案例布局”。在这个新布局中，我们要删除一些不再需要的字段，比如错误号和产品字段，然后添加我们刚刚创建的发票编号和信用状态字段。同时，我们还要添加一个文章相关列表，以便用户可以方便地查看相关的知识文章。接下来，我们要为案例对象创建一个新的Lightning记录页，并将Knowledge Standard Lightning组件添加到这个新页面中。这个组件将帮助用户更有效地查看和管理知识文章。然后，我们需要创建一个新的支持流程，这个流程将包括几个状态：新建、正在处理、已升级和已关闭。这个流程将用于管理开票案例的整个生命周期。最后，我们要创建一个新的记录类型，叫做“账单记录类型”，并启用这个记录类型给应收账款用户、管理用户和系统管理员使用。同时，我们还需要向应收账款用户配置文件添加必要的对象权限和字段级安全性，确保他们可以访问和编辑相关的字段和记录。完成这些步骤后，我们就可以在沙箱中测试这些更改了。测试无误后，我们可以使用更改集将这些更改部署到生产环境中，并在生产环境中进行最终的测试。这就是我们今天要学习的内容。希望大家能够跟上步骤，顺利完成配置。如果有任何问题，随时提问。我们开始吧！

查看详情

14

Testing Changes in a Sandbox

第 76 页

同学们，今天我们来聊聊如何在Salesforce的测试沙箱中进行更改，并确保这些更改在生产环境中也能顺利运行。首先，我们需要回到生产组织中的“应收账款需要跟踪Salesforce中的客户计费问题”这个案例。这个案例非常重要，因为它涉及到我们如何跟踪和处理客户的账单问题。接下来，我们会打开这个案例附带的两个测试脚本。这两个脚本的目的是什么呢？第一个脚本主要是用来测试我们是否能够正确地创建和更新客户账单记录。第二个脚本则是用来确保当账单出现问题时，系统能够正确地生成和分配相关的案例给相应的团队。现在，关键点来了：为了确保这些功能能够被全面测试，我们需要不同的最终用户来执行这些测试脚本。为什么呢？因为不同的用户可能会有不同的使用习惯和权限设置，只有通过他们的实际操作，我们才能发现潜在的问题和不足。所以，同学们，记住，测试不仅仅是技术人员的任务，最终用户的参与同样重要。通过他们的反馈，我们可以更好地优化我们的系统，确保它在实际使用中能够稳定、高效地运行。这就是我们今天的主要内容，希望大家能够理解并应用到实际工作中去。

查看详情

15

Lesson Agenda - 78

第 78 页

今天我们来聊聊Salesforce中的两个重要概念：课程日历管理沙盒中的更改，以及如何使用变更集来部署这些更改。首先，我们来说说“课程日历管理沙盒中的更改”。在Salesforce中，沙盒（Sandbox）是一个独立的环境，它复制了你的生产环境，但允许你在不影响实际业务的情况下进行测试和开发。想象一下，沙盒就像是一个安全的实验场地，你可以在这里尝试新的功能、修改现有的设置，或者测试新的代码，而不用担心会影响到你的实际业务数据。当你在这个沙盒环境中对课程日历管理进行更改时，比如添加新的课程、调整时间表或者修改课程内容，这些更改都只会在沙盒中生效。这样，你就可以放心大胆地进行各种尝试，直到你对更改的效果感到满意为止。接下来，我们谈谈“使用变更集部署变更”。当你完成了在沙盒中的更改，并且确认这些更改是有效的，下一步就是将这些更改部署到你的生产环境中。这时，变更集（Change Set）就派上用场了。变更集就像是一个打包好的包裹，里面装着你想要从沙盒环境迁移到生产环境的所有更改。你可以选择性地将更改添加到变更集中，比如只添加那些你确认无误的更改。然后，你可以将这个变更集发送到生产环境，并在那里进行部署。部署变更集的过程就像是将包裹从沙盒环境“邮寄”到生产环境。一旦部署完成，你在沙盒中所做的更改就会在生产环境中生效，从而影响到实际的业务操作。总结一下，课程日历管理沙盒中的更改允许你在一个安全的环境中进行测试和开发，而使用变更集部署变更则是将这些更改安全、有效地迁移到生产环境中的方法。这样，你就可以确保你的更改是经过充分测试的，并且不会对实际业务造成不必要的影响。希望这个解释能帮助你更好地理解这两个概念。如果你有任何问题，随时欢迎提问！

查看详情

16

Deploying Changes to Production

第 79 页

今天我们来聊聊如何将更改部署到Salesforce的生产环境。这个过程其实就像是你把在家里做好的菜，端到餐厅的餐桌上一样。在家里，你可以随意尝试和调整，但一旦端到餐厅，就要确保一切完美无缺。首先，你需要确保所有的更改都已经在沙盒环境中测试过了。沙盒环境就像是你的厨房，你可以在那里尝试各种新菜谱，确保味道和外观都符合预期。一旦你觉得一切都准备好了，就可以开始部署了。部署的过程通常使用Change Sets（变更集）或者更高级的工具如Salesforce DX。Change Sets就像是一个打包好的餐盒，里面装着你所有的更改。你只需要把这个餐盒从沙盒环境发送到生产环境，然后生产环境就会接收并应用这些更改。在发送之前，一定要仔细检查Change Sets中的每一项更改，确保没有遗漏或者错误。这就像是在端菜之前，检查每一道菜是否都符合标准。最后，点击“部署”按钮，Salesforce就会开始将你的更改应用到生产环境中。这个过程可能需要一些时间，具体取决于更改的复杂程度。一旦部署完成，记得在生产环境中再次测试，确保一切运行正常。这就像是在餐厅里，确保每一道菜都让客人满意。好了，这就是将更改部署到Salesforce生产环境的基本过程。希望这个比喻能帮助你更好地理解这个过程。如果有任何问题，随时问我哦！

查看详情

17

Deploying Metadata

第 80 页

今天我们来聊聊Salesforce中的元数据部署。想象一下，元数据就像是你在Salesforce中设置的所有自定义设置和配置的蓝图。比如，你创建了一个新的对象，或者设置了一些特定的字段和页面布局，这些都是元数据的一部分。现在，假设你在一个开发环境中做了很多设置和测试，觉得一切都准备好了，想要把这些设置搬到测试环境或者生产环境中去。这时候，你就需要用到元数据部署了。元数据部署的过程，简单来说，就是把你在一个Salesforce组织（比如开发环境）中设置好的元数据，打包并传输到另一个组织（比如测试或生产环境）中去。这样，你就可以在不同的环境中保持设置的一致性，确保在开发环境中测试好的功能，在测试和生产环境中也能正常工作。这个过程通常包括几个步骤：首先，你要从源组织（比如开发环境）中提取出你需要的元数据；然后，把这些元数据打包成一个部署包；最后，把这个包部署到目标组织（比如测试或生产环境）中去。通过这种方式，你可以确保你的Salesforce环境在不同阶段（开发、测试、生产）之间保持一致，减少因为环境差异导致的问题。希望这个解释能帮助你更好地理解Salesforce中的元数据部署过程！

查看详情

18

Metadata Deployment Tools

第 81 页

今天我们来聊聊Salesforce中的元数据部署工具，特别是SFDX和ANT Migration Tools。这两个工具都是用来帮助我们在不同的Salesforce环境之间迁移和部署元数据的，但它们有一些关键的区别。首先，我们得知道，元数据部署通常涉及到两个主要的环境：一个是沙箱环境，另一个是生产环境。沙箱环境是从生产环境复制出来的，用于测试和开发。有时候，我们可能还会在同一个生产组织下创建多个沙箱环境。现在，让我们来看看SFDX和ANT Migration Tools的主要区别： 1. ，安全性，：SFDX在安全性方面做得更好。使用ANT Migration Tools时，你需要将密码存储在纯文本文件中，这显然不太安全。而SFDX则允许你通过浏览器登录，这样就不需要明文存储密码了，大大提高了安全性。 2. ，临时组织，：SFDX支持使用临时组织。这些临时组织是用于短期开发和测试的，使用完毕后可以轻松丢弃。这对于快速测试新功能或修复bug非常有用。 3. ，元数据存储，：ANT Migration Tools会将元数据存储在一个中间位置。这意味着在将元数据部署到另一个组织之前，你可以修改或删除这些元数据。而SFDX则更直接，通常是将元数据直接从源代码管理系统中部署到目标环境。 4. ，源代码管理，：无论是SFDX还是ANT Migration Tools，都支持与Git等源代码管理系统集成。这意味着你可以轻松地管理代码的版本和变更，确保每次部署都是可控和可追踪的。总结一下，SFDX在安全性、临时组织的支持以及直接部署方面有优势，而ANT Migration Tools则在元数据的中间存储和修改方面提供了更多的灵活性。选择哪个工具，取决于你的具体需求和团队的偏好。希望这些信息对你有帮助！如果你有任何问题，随时问我。

查看详情

19

Distributing Components Using Unmanaged Packages

第 82 页

今天我们来聊聊如何使用非托管包来分发Salesforce的组件和应用程序。非托管包是一种非常灵活的工具，特别适合那些需要将新组件或应用程序分发到多个生产组织的场景。比如说，如果你的公司因为合并或收购，拥有了多个生产组织，这时候非托管包就能派上用场了。首先，你需要将你的组件或应用程序打包成一个非托管包。这个包可以包含你开发的新功能、自定义对象、页面布局等等。打包完成后，你可以将这个非托管包上传到Salesforce的AppExchange。AppExchange是Salesforce的一个应用市场，你可以在这里分享你的包，也可以从这里获取别人分享的包。接下来，你可以将这个非托管包部署到另一个生产组织中。部署的过程其实很简单，就像安装一个应用程序一样。你只需要在目标组织中选择这个包，然后点击安装就可以了。不过，有一点需要特别注意：非托管包一旦部署到另一个组织，你在原始组织中对这些组件或应用程序所做的任何更改，都不会自动同步到其他组织中。也就是说，每个组织中的包都是独立的，互不影响。另外，非托管包还有一个限制，就是它不允许你安装同名的组件。这意味着你不能使用非托管包来更新已经存在的组件或应用程序。如果你需要更新现有的组件，你可能需要考虑使用托管包，或者手动进行更新。总结一下，非托管包是一个很好的工具，适合在多个生产组织之间分发新的组件和应用程序。但它不适合用于更新现有的组件，也不支持跨组织的同步更新。希望这些信息对你有所帮助！

查看详情

20

Change Sets Overview

第 83 页

今天我们来聊聊Salesforce中的变更集。变更集其实就是一个打包的工具，它帮助我们把在一个Salesforce环境（我们叫它源组织）里做的更改，比如新建的字段、页面布局或者工作流规则，打包起来，然后发送到另一个环境（我们叫它目标组织）里去。首先，我们要在源组织里创建一个“传出更改集”。这个更改集就像是一个包裹，里面装着我们想要发送的所有更改。创建好之后，我们就可以把这个包裹上传到目标组织。上传之后，目标组织就会收到这个包裹，并把它看作是一个“入站变更集”。这时候，目标组织的管理员就可以查看这个变更集，看看里面都有哪些更改，然后决定是否要接受这些更改。但是，要想在两个组织之间发送变更集，我们还需要一个叫做“部署连接”的东西。这个部署连接就像是两个组织之间的桥梁，确保变更集能够安全、准确地从一个组织传到另一个组织。简单来说，变更集就是帮助我们管理和传输Salesforce环境之间更改的一个工具，而部署连接则是确保这些更改能够顺利传输的关键。希望这个解释能帮助你更好地理解变更集的概念！

查看详情

21

Steps to Deploy Metadata using Change Sets

第 84 页

同学们，今天我们来聊聊如何使用变更集（Change Sets）在Salesforce中部署元数据。变更集是一个非常方便的工具，它可以帮助我们在不同的Salesforce环境之间移动自定义设置和配置。首先，我们需要知道哪些组件可以通过变更集来部署。这些组件包括自定义对象、字段、页面布局、Apex类、触发器等等。你可以通过Salesforce的帮助文档来查看完整的列表，链接我会放在这里：[变更集可用组件](https://help.salesforce.com/articleView?id=changesets_about_components.htm&type=0)。但是，也有一些组件是不能通过变更集来部署的。比如，Lead和Case的设置、报告和仪表板的设置、团队角色、财政年度、组织范围内的电子邮件地址、委托管理以及公共日历等。这些设置通常需要在每个环境中手动配置。使用变更集的步骤大致如下： 1. ，创建变更集，：在源环境中，创建一个新的变更集，并给它一个有意义的名称。 2. ，添加组件，：将你想要部署的组件添加到变更集中。你可以选择单个组件，也可以选择多个。 3. ，上传变更集，：将变更集上传到目标环境。这通常需要你有目标环境的访问权限。 4. ，部署变更集，：在目标环境中，找到上传的变更集，并部署它。系统会提示你确认部署，并显示可能的影响。 5. ，验证部署，：部署完成后，检查目标环境，确保所有组件都按预期工作。记住，变更集是一个强大的工具，但它也有局限性。了解哪些组件可以通过变更集部署，哪些不能，可以帮助你更有效地管理Salesforce环境之间的变更。好了，这就是今天的内容。希望这些信息对你们有所帮助。如果有任何问题，随时提问！

查看详情

22

Enabling a Deployment Connection

第 85 页

今天我们来聊聊Salesforce中的部署连接。想象一下，部署连接就像是一座桥梁，连接着两个Salesforce组织。当你想要把一个组织中的更改（比如新的功能或者设置）搬到另一个组织时，这座桥就派上用场了。首先，你需要确保这座桥是“授权”的。也就是说，两个组织之间必须有一个明确的协议，允许彼此交换信息。这就像是你和朋友之间需要互相同意，才能分享彼此的玩具一样。在Salesforce中，当你设置好两个组织后，系统会自动帮你建立这座桥，也就是部署连接。但是，仅仅有桥还不够，你还需要确保目标组织（也就是你要把更改搬过去的那个组织）允许这些更改进入。这就像是你朋友家的门需要开着，你才能把玩具搬进去。所以，总结一下，使用更改集部署元数据时，你需要： 1. 确保两个组织之间有授权的部署连接。 2. 确保目标组织允许入站更改。这样，你就可以顺利地把更改从一个组织搬到另一个组织了。希望这个比喻能帮助你更好地理解部署连接的概念！

查看详情

23

Creating and Uploading Outbound Change Sets

第 86 页

今天我们来聊聊Salesforce中的收件箱更改集。首先，我们要明白什么是依赖关系。简单来说，依赖关系就像是一个链条，一个组件需要另一个或多个组件才能正常工作。比如，你有一个自定义字段，这个字段依赖于一个自定义对象。如果你只部署这个字段，而没有部署那个对象，那么部署就会失败。所以，当你创建一个外向的更改集时，一定要确保所有相关的组件都包含在内。如果目标组织中没有这些组件，你就需要把它们都加进去。接下来，记住一点，一旦你上传了更改集，就不能再修改它的内容了。如果你发现漏掉了一些重要的组件，别担心，你可以克隆这个更改集，添加那些漏掉的组件，然后再上传一次。最后，我们来看看更改集的一些限制。每个更改集最多只能包含2,500个组件，而且所有文件的总大小不能超过400 MB。所以，在创建更改集的时候，一定要计算好这些限制，避免超出。好了，这就是关于创建和卸载收件箱更改集的一些基本要点。希望这些信息对你们有帮助！

查看详情

24

Profile Settings in Change Sets

第 87 页

今天我们来聊聊Salesforce中的更改集，特别是关于如何通过更改集来管理个人资料的设置。首先，更改集是一个非常强大的工具，它允许你在不同的Salesforce环境之间迁移配置和代码。这包括你自定义的字段、页面布局、工作流规则等等。现在，重点来了——更改集还可以包括与这些组件相关的配置文件设置。比如说，如果你在Salesforce中创建了一个自定义字段，并且你为这个字段设置了字段级安全，那么这些安全设置也可以通过更改集来迁移。这意味着，当你把更改集从一个环境部署到另一个环境时，所有相关的配置文件设置也会自动跟着过去。但是，这里有个小细节需要注意：更改集并不支持所有的配置文件设置。特别是对于标准对象和标准字段的权限，比如“读取”、“创建”、“编辑”和“删除”这些权限，更改集是无法处理的。也就是说，你不能通过更改集来迁移这些标准对象的权限设置。不过，别担心，还有一个好消息！更改集是支持权限集的。权限集可以包含对标准对象权限、标准字段权限以及一些用户权限（比如“API已启用”）的访问权限。所以，如果你需要迁移这些类型的权限设置，可以通过权限集来实现。总结一下，更改集是一个非常有用的工具，可以帮助你在不同的Salesforce环境之间迁移配置和代码，包括一些配置文件设置。但是，它并不支持所有的配置文件设置，特别是标准对象和字段的权限。对于这些，你可以考虑使用权限集来补充。希望这能帮助你更好地理解和使用Salesforce中的更改集和配置文件设置。如果有任何问题，随时提问哦！

查看详情

25

Tracking Changes

第 88 页

今天我们来聊聊Salesforce中的一个非常实用的功能——，审计跟踪历史记录，。这个功能可以帮助你跟踪组织中的各种设置更改，看看是谁在什么时候做了哪些改动。听起来是不是有点像侦探工作？没错，它确实能帮你“破案”哦！ ### 1. ，审计跟踪历史记录的作用，审计跟踪历史记录的主要作用是记录组织中的设置更改。比如，某个功能突然不工作了，你可以通过这个功能查看最近有没有人对相关设置做了改动。这样，你就能快速找到问题的根源。 ### 2. ，谁做了更改？，在审计跟踪历史记录中，你会看到两列信息：，用户，和，委托用户，。这两列会告诉你，是谁进行了更改。如果你发现某个用户频繁地修改重要设置，可能意味着他拥有过多的“管理”权限。这时候，你可能需要考虑调整权限分配了。 ### 3. ，下载历史记录， Salesforce允许你下载过去180天的完整设置历史记录。这个功能非常有用，尤其是当你需要向管理层或审计团队汇报时，可以直接提供详细的历史数据。 ### 4. ，在沙箱中使用，审计跟踪历史记录不仅在正式环境中有用，在沙箱环境中也同样重要。你可以用它来跟踪你在沙箱中做的所有更改。这样，当你准备把这些更改部署到正式环境时，就能清楚地知道哪些组件需要添加到，传出更改集，中。 ### 5. ，新春天20的新功能，在最新的，新春天20，版本中，Salesforce增加了一些新的事件类型，专门用于跟踪以下设置更改： - ，邮件到达率，：你可以跟踪邮件的发送和接收情况，确保邮件系统正常运行。 - ，已连接的应用程序，：如果你使用了第三方应用程序，现在可以跟踪这些应用程序的设置更改。 - ，通知，：你可以跟踪系统中的通知设置，确保重要的通知没有被误改。 ### 总结审计跟踪历史记录是一个非常强大的工具，能帮助你监控组织中的设置更改，快速诊断问题，甚至还能帮助你优化权限管理。特别是在新春天20版本中，新增的事件类型让这个功能更加全面。好了，今天的课程就到这里。希望你能好好利用这个功能，让你的Salesforce组织更加安全和高效！如果有任何问题，随时问我哦！

查看详情

26

Deploying Inbound Change Sets

第 89 页

今天我们来聊聊Salesforce中的部署入站变更集。这个功能非常有用，特别是当你需要将开发环境中的更改应用到生产环境时。首先，记住一点：当你把更改集上传到目标组织时，它并不会自动部署。你需要手动选择部署。在部署之前，你可以选择验证更改集。验证的好处是，你可以提前看到如果部署的话，哪些会成功，哪些可能会失败。这样，你就可以提前解决问题，避免在生产环境中遇到麻烦。更改集的部署是一个整体事务。这意味着，如果部署过程中有任何一部分失败了，整个部署都会回滚。比如，如果你尝试部署一个组件，但这个组件依赖于另一个在目标组织中不存在的组件，那么整个部署就会失败。一旦部署成功，所有的更改就会提交到你的组织中，而且这些更改是无法回滚的。所以，在部署之前，一定要确保所有的更改都是正确的。你可以在“设置”中的“部署状态”查看更改集的部署历史记录。接下来，我们来看看更改集的测试选项。在部署或验证更改集时，你可以选择不同的测试选项。这些选项可以帮助你控制测试的范围，从而节省时间。 - ，默认，：在沙箱中，不执行任何测试。在生产中，如果更改集包含Apex类或触发器，则会执行所有本地测试。 - ，运行本地测试，：运行组织中的所有测试，但源自已安装的托管包的测试除外。 - ，运行所有测试，：运行组织中的所有测试，包括托管包的测试。 - ，运行指定的测试，：仅运行你指定的测试。最后，我们来看看验证可能失败的一些常见原因： - 顶点测试失败 - 超出限制（比如查阅字段数、文本区数等） - 生产组织中未启用某项功能 - 缺少对组件的引用 - 当某个字段被Apex/Visualforce引用时，你正在尝试更改该字段的数据类型希望这些信息对你有帮助！如果你有任何问题，随时问我。

查看详情

27

Change Set Considerations

第 90 页

今天我们来聊聊Salesforce中的更改集，以及使用它们时需要注意的一些关键点。更改集是一个非常方便的工具，可以帮助我们在不同的Salesforce环境之间迁移配置和自定义设置。但是，它并不是万能的，有一些限制和注意事项我们需要了解。首先，更改集并不支持所有的元数据组件和配置文件设置。这意味着，有些组件和设置不能通过更改集来迁移，你需要手动将它们添加到目标组织中。这就像是你搬家时，有些家具太大或者太复杂，不能通过搬家车来运输，你得自己想办法搬过去。其次，更改集不能用于删除目标组织中的元数据组件。如果你在源组织中删除了某个组件，这个删除操作不会通过更改集传递到目标组织。你需要在目标组织中手动删除这些组件。这就像是你搬家时，决定不再需要某个旧沙发，但你不能指望搬家车帮你处理掉它，你得自己安排处理。另外，如果你在源组织中重命名了一个元数据组件，更改集会把这个重命名的组件视为一个全新的组件。这意味着，在目标组织中，你需要手动去重命名这个组件，以保持一致性。这就像是你给家里的某个家具重新命名了，但搬家车不会自动帮你更新标签，你得自己动手。最后，当你部署更改集时，新的元数据会覆盖目标组织中的现有元数据，而不是合并。这意味着，如果你在目标组织中对某个组件做了修改，这些修改可能会被源组织中的版本覆盖。所以，在部署之前，一定要确保你已经备份了重要的更改。总结一下，使用更改集时，你不能用它来删除或重命名组件。要删除组件，你需要在目标组织中使用设置菜单手动操作。同样，重命名的组件也需要在目标组织中手动重命名。希望这些信息能帮助你在使用更改集时更加得心应手！

查看详情

28

Goal: Deploy the billing cases changes from sandbox to production.

第 91 页

同学们，今天我们来学习如何将计费案例的更改从沙箱部署到生产环境。这个过程涉及到几个关键步骤，我会一步步带你们了解。首先，我们需要在生产环境中设置，允许从沙箱接收更改。这一步很关键，因为如果不允许入站更改，我们就无法将沙箱中的更新推送到生产环境。接下来，我们回到沙箱环境，创建一个名为“计费案例更改集”的传出更改集。这个更改集包含了所有我们需要部署到生产环境的更改。根据我们的变更列表，这个更改集应该包括以下几个组件： - 案例自定义字段：发票号和信用状态 - 案例页面布局：计费案例布局 - 病例记录类型：计费 - 应收账款用户配置文件的解决方案对象权限更改创建好更改集后，我们就可以将其上传到生产环境了。在生产环境中，我们需要卸载并部署这个入站更改集。这一步确保了所有的更改都被正确地应用到了生产环境。部署完成后，我们还需要为应收账款用户配置文件进行一些设置，确保他们能够访问和使用这些新更改。最后，别忘了手动激活案例的闪电记录页面。这一步确保了用户界面能够反映出我们刚刚部署的所有更改。整个过程大约需要15分钟，但请确保每一步都仔细检查，以避免任何可能的错误。这样，我们就成功地将计费案例的更改从沙箱部署到了生产环境。希望这个过程对你们来说既简单又明了。如果有任何疑问，随时提问！

查看详情

29

How Would You Restrict Users…

第 93 页

让我们来聊聊如何在Salesforce中限制用户访问生产组织，特别是在部署和测试更改时。这个问题很关键，因为生产环境是存放我们实际业务数据的地方，任何未经授权的访问都可能导致数据泄露或其他严重问题。首先，我们可以考虑使用，权限集，和，配置文件，来限制用户的访问权限。通过为不同的用户分配不同的权限集或配置文件，我们可以精确控制他们能访问哪些数据和功能。比如，我们可以创建一个只允许查看数据的权限集，这样即使用户在生产环境中，他们也无法进行任何修改操作。，优点，：这种方法非常灵活，可以根据具体需求定制权限。，缺点，：需要仔细管理权限集和配置文件，确保没有遗漏或错误。其次，我们可以使用，沙盒环境，来进行测试和部署。沙盒是Salesforce提供的一个与生产环境隔离的测试环境。我们可以在沙盒中进行所有的开发和测试工作，确保一切正常后再将更改部署到生产环境。，优点，：沙盒环境与生产环境完全隔离，不会影响实际业务数据。，缺点，：需要定期刷新沙盒数据，以保持与生产环境的一致性。最后，我们还可以使用，变更集，来管理部署。变更集是一种将更改从沙盒环境迁移到生产环境的工具。通过变更集，我们可以控制哪些更改被部署到生产环境，并在部署前进行详细的审查和测试。，优点，：变更集提供了一种结构化的方式来管理部署，减少了出错的可能性。，缺点，：变更集的使用需要一定的学习和实践，初次使用时可能会有些复杂。总结一下，限制用户访问生产组织的方法有很多，每种方法都有其优缺点。我们可以根据具体的业务需求和安全要求，选择最适合的方法来保护我们的生产环境。希望这些信息对你有所帮助！

查看详情

30

How Would You Restrict Users… - 94

第 94 页

今天我们来聊聊一个非常实际的问题：，如何限制用户在部署和测试更改时访问生产环境，。这个问题在Salesforce的管理中非常重要，因为生产环境是你们公司实际运营的核心系统，任何未经测试的更改都可能带来风险。 ### 1. ，使用权限集和配置文件，首先，我们可以通过，权限集（Permission Sets），和，配置文件（Profiles），来限制用户的访问权限。你可以为那些不需要访问生产环境的用户设置一个专门的配置文件或权限集，限制他们只能访问沙盒环境。 - ，优点，：简单直接，易于管理。 - ，缺点，：如果用户需要临时访问生产环境，可能需要频繁调整权限，管理起来可能会有些繁琐。 ### 2. ，使用登录时间限制，另一个方法是，设置登录时间限制，。你可以通过Salesforce的登录时间策略，限制用户只能在特定的时间段内登录生产环境。比如，你可以设置只有在部署和测试的时间段内，某些用户才能登录生产环境。 - ，优点，：可以有效防止用户在非工作时间访问生产环境。 - ，缺点，：如果用户需要在非工作时间进行紧急操作，可能会受到限制。 ### 3. ，使用IP范围限制，你还可以通过，IP范围限制，来控制用户访问生产环境。你可以设置只有来自公司内部网络的IP地址才能访问生产环境，这样即使有用户的登录凭证，也无法从外部网络访问。 - ，优点，：安全性高，可以有效防止外部访问。 - ，缺点，：对于需要远程工作的用户来说，可能会带来不便。 ### 4. ，使用自定义审批流程，最后，你可以设置一个，自定义审批流程，，要求用户在访问生产环境之前必须获得批准。你可以通过Salesforce的流程自动化工具（如Flow或Process Builder）来实现这一点。 - ，优点，：灵活性高，可以根据具体情况进行审批。 - ，缺点，：可能会增加管理的工作量，尤其是在需要快速响应的情况下。 ### 总结每种方法都有其优点和缺点，具体选择哪种方法取决于你们公司的实际需求和操作习惯。你可以根据实际情况，灵活组合使用这些方法，以达到最佳的管理效果。希望这些内容对你们有所帮助！如果有任何问题，欢迎随时提问。

查看详情

31

Knowledge Check

第 95 页

让我们来简单回顾一下这些Salesforce的知识点，确保大家都能跟上。首先，关于沙箱的刷新。沙箱是Salesforce中用于测试和开发的环境，它从生产环境中复制数据。管理员需要定期刷新沙箱，以确保测试环境中的数据是最新的。开发人员专业沙箱每天可以刷新一次，并且可以加载高达1GB的数据。但是，如果你使用的是开发人员沙箱，那么你只能加载200MB的数据。部分数据沙箱和已满的沙箱的刷新频率更低，分别是每5天和每29天刷新一次。接下来，我们谈谈元数据的移动。Salesforce提供了两种工具来帮助你在不同的组织之间移动元数据：Salesforce Platform IDE和Salesforce Platform迁移工具。这两种工具可以用于在两个不相关的组织之间移动元数据，比如两个生产环境。而变更集则只能用于在相关的组织之间移动元数据，比如生产环境和沙箱之间。关于变更集的一个重要注意事项是，一旦你上传了变更集，你就不能更改它的内容了。如果在变更集中缺少某些依赖组件，而这些组件在目标组织中不存在，那么部署就会失败。为了解决这个问题，管理员需要克隆变更集，添加缺少的依赖组件，然后上传新的变更集。最后，当管理员创建变更集时，应该包含自定义域和所有配置文件。这样做的好处是，自定义字段的字段级安全设置会自动包含在变更集中，这样可以确保在部署时，所有的安全设置都能正确应用。希望这些解释能帮助大家更好地理解Salesforce的这些功能和最佳实践。如果有任何疑问，随时提问！

查看详情

ADX211

课程介绍

课程章节