salesforce零基础学习（一百四十）Record Type在实施过程中的考虑

本篇参考：

我在之前的博客中简单介绍过Record Type的使用，当时作为开发人员，需要考虑的就是根据需求，创建Record Type，设置 Picklist Values以及相关的 layout，然后就完成工作。其实对于大部分的Salesforce从业者来说，基本在项目上都接触过Record Type，如果不知道Record Type是什么以及如何简单使用的可以移步之前的record type文档或者查看官方文档。作为既有系统的设置，或许简单修修补补或者不断增加逻辑很简单，如果系统第一次考虑要不要上 Record Type以及上的话，我们应该考虑哪些问题呢？本篇我们以 Lightning环境进行归纳和整理。

一. 是否需要 Record Type

1. 业务需求

是否需要不同的流程：确定不同的组或部门是否需要不同的业务流程。Record Type可以实现不同的组或者部门显示不同的定制的布局和选项列表值。
数据分组：决定是否需要出于不同目的对同一对象的记录进行分组/分段。例如，潜在客户可以分为不同类型，例如“零售”和“企业”。

如果我们有这方面的需要，则可以启用 Record Type，否则不需要启用。

二. 上 Record Type前考虑点

1. 迁移和集成

数据迁移：需要有清晰的数据清洗的逻辑，是所有的历史数据都设置指定的 Record Type还是要基于逻辑对不同数据设置不同的Record Type。

历史数据可能存在owner是inactive的情况，可以基于上方的参考文档进行操作。

数据集成：如果上下游系统有对这个表进行CRUD操作，需要联系上下游关于 Record Type的改动以及继承相关文档。举个例子：如果对方使用标准 REST API进行数据插入，我们需要告知相关team 如何获取到指定的 RecordTypeId 以及如何在requestBody中设置 RecordTypeId。如果集成系统获取salesforce系统的数据用于报表等操作，还需要告知相关team去进行filter来避免数据混乱。

2. Picklist Value

需要有清晰的逻辑关于不同的 Record Type所可以设置的 Picklist Value的值，如果Picklist Value进行了缩减，需要检查一下历史数据中的值是否有在范围之外的，如果存在并且需求确定，需要将将这个字段的 Restrict选项反选，上线后也要手动检查所有的 Picklist Values是否和预期相同。

3. Page Layout 以及 Lightning Record Page

Page Layout： 如果系统是 classic或者系统是Lightning 但是没有启用 dynamic form以及其他的部分相同，我们需要考虑通过 Page layout来实现不同的 Record Type显示不同的UI，需要清晰的设计来设置Laytout。

Lightning Record Page：如果系统启用了 Dynamic Form或者不同的Record Type需要展示的页面不同(不只是Layout)，我们需要考虑 Lightning Record Page创建，原则上最好每个 Record Type设置一个相关的 Lightning Record Page来设置页面布局，并且要基于Record Type来分配页面的访问。

建议最后还要设置一个org默认的Lightning Record Page，即使最后没有满足的页面，我们还可以保证Salesforce可以重定向到我们设置的默认页面从而避免死循环。

4. Profile 以及 Permission Set

Profile和Permission Set都可以设置所可以访问的 Record Type。

如果系统基于 Profile来设计，设计者或者架构师需要考虑不同的 Profile所可以访问的 Record Type以及设置的 Default Record Type。

如果系统基于Permission Set来设计，设计者或者架构师需要考虑如何维护不同的人所对应的不同的 Record Type的访问权限设置。

不要使用Record Type作为访问控制机制。Profile Assignment只会控制对象的创建和编辑访问权限，但不控制读取访问权限。例如，Account有 Agency 以及Business两个Record Type，Sales Profile User只设置了Agency Record Type然后当前系统设置的Account的权限是 Public Read/Write，代表着Sales Profile User可以访问并且编辑Business Record Type的Account记录，只是无法创建而已。

5. Report & Dashboard & ListView

当我们启用Record Type以后，数据进行了分组。我们需要保证既有的 Report的Filter是业务所需要的，如果业务需要所有数据，则不必修改，如果只需要某个Record Type的数据，则需要增加 Filter来过滤指定的 Record Type。这个考虑适用于 Report 以及 Dashboard以及ListView。

6. Validation Rule & Automation

Validation Rules: 修改或创建VR以支持每种Record Type的特定需求。

Automation: 更改 workflows, process builders, flows, and approval processes 来处理不同的记录类型所对应的流程。

7. 自定义功能检查

自定义组件：如果org上有自定义的组件，比如 aura / lwc，如果只是通过 Record Id来获取数据，风险较小可以忽略。如果系统中有获取当前表的 Picklist Value或者列表检索等，需要检查并且做出适当的逻辑修改。

Trigger：需要检查一下当前的表的Trigger的逻辑是否针对指定的 record type并且做出相应的处理。同时需要检查父表或者关联表有没有trigge中对当前的表进行DML操作，如果有同样需要分析并且相关处理。

8. 测试和培训

测试：如果当前的表在业务中是独立的，很幸运我们相对来说好测试。如果这个表是一个比较复杂的表，在系统中有庞大的逻辑，我们需要准备 regression test的测试用例来进行充足的测试并且进行部署演练。

培训：我们需要整理好文档来告诉 end user如何使用 Record Type。这里包括两部分，一个是如何使用新增加的功能，另外一个是如何去调整 Report 以及Listview（如果他们有创建权限）。

针对功能培训，我们需要区分不同的场景然后做不同的培训，举个例子，如果一个Profile只有一个Record Type，对于用户来说其实是无感操作，可能就不需要培训UI上的操作的不同。如果Profile包含两个及以上，我们需要培训新的UI以及新的操作。

9. 可扩展性以及文档

当我们进行了一期的实施以后，我们需要整理好文档，关于部署的准备，测试的流程以及客户培训等，后续如果Record Type需要增加，我们可以参考既有的流程来规避一些潜在风险以及提高效率。

三. Record Type部署举例

我们在实际的需求确定以后，一定是在sandbox测试完成以后才可以进行部署的，这里推荐的是使用metadata api方式部署而不是change set。使用 metadata api的好处是我们从 retrieve -> deploy可以所见即所得，通过资源比对工具可以很直观的了解我们上了哪些，资源差异等。模拟的需求特别简单，Account表有两个 Record Type，Retail 以及 Enterprise。实现以下的需求：

Admin, Sales，Support可以创建 Retail的Account，并且默认Record Type为Retail
Admin, Sales, Marketing, Support可以创建Enterprise的Account，Marketing默认的Record Type为Enterprise
Retail以及 enterprise拥有不同的UI，不同的Flexipage以及相关picklist values（一些picklist values相同并且全部选择）

针对上述需求部署的情况下，metadata xml list可以使用下述进行思考。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Package xmlns="http://soap.sforce.com/2006/04/metadata">

    <types>

        <members>Account.AccountSource</members>

        <members>Account.Industry</members>

        <name>CustomField</name>

    </types>

    <types>

    <members>Account.Enterprise</members>

    <members>Account.Retail</members>

    <name>RecordType</name>

  </types>

    <types>

        <members>Account_Record_Page</members>

        <members>Enterprise_Record_Page</members>

        <name>Flexipage</name>

    </types>

    <!--

    Profile 检索时，如果有特殊字符，比如冒号: 需要使用转义字符

    -->

    <types>

        <members>Admin</members>

        <members>Custom%3A Marketing Profile</members>

        <members>Custom%3A Sales Profile</members>

        <members>Custom%3A Support Profile</members>

        <name>Profile</name>

    </types>

    <types>

        <members>Account-Retail Account Layout</members>

        <members>Account-Enterprise Account Layout</members>

        <name>Layout</name>

    </types>

    <version>61.0</version>

</Package>

<!--

manual action:

1. 检查Record Type的picklist values

2. 检查 Page Layout Assignment

3. Flexipage 设置Assignment（手动配置比部署更容易）

-->

总结：本篇主要汇总了一下当我们想要启用 Record Type情况下，需要考虑哪些关键点从而将风险达到最低。当然需要考虑的不一定仅有这些，不同的表实施上以及考虑上可能还有一些别的区别，可以查看上方的官方文档进行更多的思考。篇中有错误欢迎指出，有不懂欢迎留言。