# Salesforce / CM / BI Final Briefing Sheet

Date: `2026-07-07`

## 用法

这份文档是
`最终汇报口径页`
。

它不再扩展新证据，
只固定 4 类内容：

- `最稳的 10 句结论`
- `标准说法`
- `不要这样说`
- `最容易被问的 5 个问题`

如果你现在要对外同步、
开会口头讲、
或者写一个短结论，
优先看这份。

如果要回到一页证据摘要，
看：

- [salesforce-cm-bi-report-group-summary-matrix-2026-07-07.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-cm-bi-report-group-summary-matrix-2026-07-07.md)

如果只要超短口头版，
看：

- [salesforce-cm-bi-verbal-summary-2026-07-07.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-cm-bi-verbal-summary-2026-07-07.md)

## 最稳的 13 句结论

1. 这批 BI 报表里看到的 gap，**大多数不该直接读成 `CM 没能力`**。
2. 当前最常见的差异，不是对象不存在，而是 `PingCAP L2 parity`、`semantic mismatch`、`activation-state mismatch` 还没完全对齐。
3. `Salesforce 现网` 还在持续补很多报表语义，尤其集中在 `Lead`、`Opportunity`、`Quote`、`Order`、`CampaignMember`、`Account/Org__c` 这几条主链。
4. `CM` 这边已经接住了大量 substrate，包括字段、公式、rollup、validation、record-triggered Flow，以及不少关键对象主链。
5. 当前最该优先修的，通常不是 runtime，而是 **和 front-door 报表最近的 exact-name parity 缺口**。
6. 真正更像 `CM 真 gap` 的，不是“少一条业务 Flow”，而是 **同面 parity 清完以后仍然残留的 Apex trigger / runtime 逻辑**。
7. 现在最接近 true runtime 的，主要只有 3 组：`Lead runtime`、`Opportunity / Quote runtime`、`Finance runtime`。
8. `CampaignMember / Contact` 和 `Account` 这两组，现在还更应该放在 `runtime candidate` 桶里，而不是直接宣布为 CM 真边界。
9. 最值得先盯的 front-door 仍然是：`fd12...`、`1733...`、`837...`、`f9c4...`。
10. 所以默认动作始终是：**先按报表面修 parity，再决定要不要升级成 runtime**。
11. 当前还能更硬地说的是：优先盯的主 front-door 不只 report-backed，而且多数还能看到最近一次活动时间、sample user 和 datasource family；但次级 consumer 里仍有一部分只是 `lineage-backed`，不能一律讲成同级别 front-door。
12. 当前还不能更硬地说的是：这些 sample user 就是 canonical dashboard owner。
13. 对 `Account / Tenant` 这组 front-door，当前最好再拆成 4 个家族去讲：`account forecast`、`tenant ops`、`cloud billing owner/allocation`、`PLG funnel`，不要混成一个泛泛的 `account report`。
14. `Account_Contract_Valid_Message` 这类 contract-valid 治理链，当前更稳的口径是：**已有 warehouse/modeling consumer，repo 侧也只坐实到 `stg_salesforce_account` 这类 staging/schema preservation；还出现过更弱的 Looker Studio exploratory evidence，而且这层 BI 证据更像同一秒 `51` 条 `51` 个 distinct query 的字段探索 burst，不是已坐实的 report-backed front-door direct hit**。

## 标准说法

### 一句话版本

`当前这批差异大多数不是 CM 没能力，而是 CM 已有 substrate，但 PingCAP L2 和 live Salesforce 还没完全对齐；真正更像 CM 真 gap 的，主要是 parity 清完后剩下的 Lead、Opportunity/Quote、Finance 三类 runtime 残余。像 contract-valid 这类链条，现在更像“建模层已消费、前台报表未坐实”的治理 parity，不该和 current-order-type 混成同一档。`

### 30 秒版本

`现在最稳的结论是：报表里列出来的 gap 不能直接等同于 CM 做不到。大多数差异还停留在 L2 parity、语义不一致、或者激活态不一致。CM 已经接住了很多对象和自动化主链，真正更像平台边界的，主要是 Lead、Opportunity/Quote、Finance 这三组在 parity 清完后仍然残留的 trigger/runtime 逻辑。`

### 2 分钟版本

`如果按报表组看，Pipeline/Forecast、Lead Funnel、Campaign Attribution、Order/ARR/RevRec、Account/Tenant 这几组，当前都已经能看到 Salesforce 现网还在补的自动化语义。CM 这边并不是空白，很多关键字段、公式、rollup、validation 和 Flow 已经在了。现在最常见的问题是 exact-name parity 没补齐、semantic mismatch、activation-state mismatch，而不是平台没能力。真正需要单列成 runtime 题的，主要还是 Lead、Opportunity/Quote、Finance 三类 residual trigger 逻辑。`

## 不要这样说

| 不建议说法 | 更稳的替代说法 |
|---|---|
| `报告里这些都是 CM 做不到` | `报告里这些是 Salesforce 与当前 CM+L2 实现之间的差异来源` |
| `Campaign 这块 CM 不支持` | `当前更像 CampaignMember parity 和 Contact stitching parity 未补齐` |
| `Account 这块就是平台能力问题` | `当前更像 Account dimension / shared-key parity，后面才可能剩 Account runtime candidate` |
| `Finance 这块全是 runtime gap` | `当前先看 Order/Revenue/Collections/line-item parity，清完后剩下的才是 finance runtime` |
| `这个 report title/owner 已经确定了` | `当前能强说的是 report-backed consumer surface 和 recent sample users，title/owner metadata 还不完整` |

## 最容易被问的 5 个问题

**Q1. 报告里列出来的 gap，是不是都算 `CM 做不到`？**

不是。当前大多数更像
`L2 exact-flow parity`
、
`semantic mismatch`
、
`activation-state mismatch`
，
不是平台能力空白。

**Q2. 那什么才最接近 `CM 真 gap`？**

是那些在同一报表面上，
把已知 parity 清完以后，
仍然只能靠 live Salesforce `Apex trigger / runtime`
维持的残余逻辑。

**Q3. 现在最像 true runtime 的是哪些？**

- `LeadTrigger / LeadAITrigger`
- `OpportunityTrigger / QuoteTrigger`
- `OrderTrigger / RevenueTrigger / custom line-item trigger surfaces`

**Q4. 哪些现在还不该直接升成 runtime？**

- `Trigger_CampaignMember` / Contact residuals
- `AccountTrigger` residuals

因为它们前面还有明确的
`Campaign_Member_Key_Message_Update`
、
`Account_Current_Order_Type`
、
`Account_Partner_Sales_Owner_Set`
、
`Account_Contract_Valid_Message`
这类 parity 要先补。

**Q5. 如果现在就开始排查，顺序是什么？**

默认顺序：

1. `fd12...`
2. `1733...`
3. `837...`
4. `f9c4...`

并且每张报表都先清 parity，
再决定要不要升级成 runtime。

## 最短收口

`最稳的口径不是“CM 普遍没有能力”，而是“CM 已有不少主链能力，当前最大的差异仍然是 L2 parity、语义不一致，以及少量真实 runtime 边界”。`