连接散布的数据流：我使用 Salesforce 联合报表的历程

在 Salesforce 的日常工作中，我们经常会遇到这样的需求：一份报表需要整合来自不同关联路径的数据，或者从多个角度审视同一个对象的数据。标准的报表类型，无论是“Opportunity with Products”还是“Opportunity with Cases”，都只能提供一个相对线性的、预设好的数据视图。我遇到的一个典型场景，让我不得不深入研究并最终选择使用联合报表（Joined Reports）。

需求之初：标准报表的瓶颈

当时的需求是这样的：我们想追踪销售机会（Opportunity）的健康状况，不仅要看它的销售阶段和金额，还需要同时查看该机会关联的未关闭活动（Activities）数量，以及关联的未关闭支持案例（Cases）数量。更重要的是，我们还需要看到那些没有关联活动或案例的机会，并对它们进行单独的汇总分析。

我首先尝试了标准的报表类型：

• “Opportunities with Activities”：这个报表类型很适合查看机会和它们关联的活动，但它只会列出有活动的记录，那些没有活动的机会就直接被过滤掉了。而且，我无法在同一个视图里直接看到 Cases 的信息。
• “Opportunities with Cases”：同理，这个报表类型只关注有 Cases 的机会。
• “Opportunities with Activities and Cases”：Salesforce 并没有直接提供这样多层复杂关联的标准报表类型，即使有，也很可能也是内连接（INNER JOIN）的逻辑，依然会丢失那些“不完整”的数据。

很明显，单一的报表类型无法满足需求。我需要一个能像 SQL 的 `FULL OUTER JOIN` 或 `LEFT JOIN` 组合那样，灵活地从不同维度拉取数据，并且能保留主对象（Opportunity）的完整性。

自定义报表类型（CRT）的考量与放弃

我的第二个想法是创建一个自定义报表类型 (Custom Report Type, CRT)。CRT 在很多场景下都非常强大，它允许我们定义多达 4 层的父子关系，并且可以选择关联类型（A to B `with` B records 或 A to B `without` B records）。

我当时考虑：

• 是否可以创建一个“Opportunities with Activities”并将其作为主对象，然后进一步关联“Cases”？

但很快就发现问题：CRT 的本质是将所有关联对象的数据“展平”成一张大表。如果一个 Opportunity 有 3 个 Activity 和 2 个 Case，那么在 CRT 中，这个 Opportunity 会被重复显示 6 次（3 * 2），每一行对应一个 Activity 和一个 Case 的组合。这会导致数据严重重复，且在汇总时非常麻烦，无法准确统计 Opportunity 的总数，或者某个 Opportunity 到底有多少 Activity 和多少 Case。

我需要的是在同一个 Opportunity 的“行”下，分块显示其相关的 Activity 和 Case 摘要，而不是将其数据交叉相乘。CRT 显然无法实现这种“分块”的视图。

转折点：联合报表（Joined Reports）登场

在我反复思考如何避免数据重复和丢失非关联数据时，我突然想到了联合报表。虽然之前也听说过，但一直觉得它过于复杂，或者说没有遇到非它不可的场景。

为什么联合报表是答案？

联合报表的核心优势在于它允许我们将多个独立的报表块（Report Blocks）组合到一个报表中，每个报表块本质上都可以是一个标准的报表类型。这些报表块可以有自己的字段、过滤器和汇总规则，然后通过一个或多个“公共字段”（Common Fields）将它们关联起来，形成一个统一的视图。这完美地解决了我的问题：

• 保留主对象完整性： 我可以创建一个基于“Opportunities”的报表块，包含所有机会，无论它们是否有活动或案例。
• 分块显示相关数据： 我可以添加第二个报表块基于“Opportunities with Activities”，第三个报表块基于“Opportunities with Cases”。每个块独立地拉取数据。
• 灵活的关联与汇总： 通过 Opportunity Name 或 Opportunity ID 作为公共字段，我可以将这些独立的块按照机会进行分组。然后，每个块内部可以进行自己的汇总，例如统计活动数量、未关闭案例数量。

实践中的挑战与取舍

构建联合报表并非一帆风顺，过程中我也遇到了一些需要理解和适应的地方：

1. 公共字段的选择与理解

这是联合报表最关键也最容易让人混淆的地方。报表块之间并非直接 JOIN，而是通过“公共字段”来实现分组对齐。我一开始总是想着要找一个像 SQL JOIN ON 子句那样的关联字段，但 Salesforce 的逻辑是：你需要选择一个或多个字段，这些字段存在于所有报表块中，并且能够代表你想要分组的主维度。

在我的场景中，Opportunity Name 和 Opportunity ID 都是很好的公共字段。我通常倾向于使用 ID，因为它是唯一的且不易变动，而 Name 可能会有重复或人为修改。选择了公共字段后，报表会基于这些字段进行分组，每个报表块中的数据都会在对应的分组下显示。

// 假设有以下三个报表块：
// Block 1: Opportunities
// Block 2: Opportunities with Activities
// Block 3: Opportunities with Cases

// 选择 Common Fields: Opportunity ID, Opportunity Name

// 最终报表结构会是：
// Group By: Opportunity ID, Opportunity Name
//   Opportunity A (ID: 006...)
//     Block 1 Data: Opp A Details (Stage, Amount)
//     Block 2 Data: Activity 1 (Subject), Activity 2 (Subject)
//     Block 3 Data: Case 1 (Subject), Case 2 (Subject)
//   Opportunity B (ID: 006...)
//     Block 1 Data: Opp B Details (Stage, Amount)
//     Block 2 Data: (No Activities found)
//     Block 3 Data: Case 3 (Subject)
// ...

这里需要注意的是，如果某个报表块中的某条记录在公共字段上没有匹配到其他块的数据，它仍然会显示在该公共字段的分组下。例如，如果 Opportunity B 没有 Activities，那么在 Opportunity B 的分组下，Block 2 会显示为空或不出现相关数据行，但 Opportunity B 本身及其 Block 1 和 Block 3 的数据仍然会完整显示。这正是解决“丢失没有关联数据”的关键。

2. 过滤器（Filters）的作用范围

联合报表的过滤器可以应用于整个报表（All Blocks），也可以应用于单个报表块。这提供了极大的灵活性。

• 如果我想筛选所有处于“Closed Won”阶段的机会，我会将过滤器应用于“All Blocks”。
• 但如果我只想看“未关闭的活动”和“优先级高的案例”，那么我会将这些特定的过滤器应用到对应的“Opportunities with Activities”和“Opportunities with Cases”报表块中。这样，主机会块仍然会显示所有机会，但关联的活动和案例数据则会根据其各自的过滤器进行筛选。

3. 自定义汇总公式（Custom Summary Formulas）

在联合报表中，自定义汇总公式可以应用于整个报表，也可以应用于特定的报表块。最强大的是，你可以创建跨块的公式。例如，我想计算“平均每个机会的活动数量”，或者“有机会但没有未关闭案例的机会占比”。

我当时的需求是想在一个总计行中显示：

• 总机会数（COUNT of Block 1 rows）
• 总活动数（COUNT of Block 2 rows）
• 总案例数（COUNT of Block 3 rows）

这些可以通过在不同块上添加 COUNT 或 SUM 汇总字段，然后在总计行中直接引用或通过自定义公式实现。例如，在 Grouping level 上创建一个公式，比如 RowCount / PARENTGROUPVAL(RowCount, 'Opportunity.Id') 来计算某个子集的比例，或者 BLOCK_A.RowCount + BLOCK_B.RowCount 来进行跨块的简单加和。

不过，跨块公式的逻辑需要仔细设计，尤其是当涉及到不同粒度的数据时。例如，直接对 Block 2 的 RowCount 求和，得到的是总活动数，而不是拥有活动的 Opportunity 数量。

4. 导出与仪表板组件的限制

联合报表的导出格式相对复杂，它会保持原始的块结构，而不是展平为一张简单的 CSV 表。这在需要将数据导入其他系统进行进一步分析时，会增加后期处理的负担。

在仪表板组件方面，联合报表也不是万能的。虽然可以用于一些图表组件（如表格、条形图），但对于某些复杂的仪表板组件（如量表、漏斗图等），可能不支持或表现不佳。这需要根据具体的需求进行测试和取舍。

我的结论与当前看法

在我这次经历中，联合报表无疑是解决特定复杂数据聚合需求的利器。它填补了标准报表类型和自定义报表类型在某些场景下的空白，特别是当我们需要：

• 整合来自多个独立数据流（不同关联路径）的信息。
• 在单个报表中同时显示“有”和“没有”某个关联对象的主记录。
• 需要对不同数据块进行独立的过滤和汇总，并在更高层次上进行聚合分组。

然而，我也认识到联合报表的缺点：

• 构建复杂： 它的学习曲线比标准报表陡峭，配置起来也更耗时。
• 性能考量： 块越多、数据量越大，报表加载时间可能会越长。
• 可维护性： 对于不熟悉联合报表的人来说，理解和修改一个复杂的联合报表会比较困难。

因此，我现在的策略是：除非标准报表或简单的自定义报表类型确实无法满足需求，否则我不会轻易选择联合报表。但一旦遇到像上述那样，需要“多角度、保留完整性、分块聚合”的需求时，联合报表依然是我的首选。它能够让我以一种相对优雅的方式，在 Salesforce 原生工具中，实现很多原本需要导出数据到外部工具才能完成的复杂分析。

目前，我仍然希望 Salesforce 能在联合报表的导出格式和仪表板支持上做进一步的优化，使其在更广泛的场景下，能够提供更无缝的用户体验。