# Salesforce / CM / BI Report-Group Summary Matrix

Date: `2026-07-07`

## 用法

这份文档是
`一页汇报版`
。

如果对象表、字段表、front-door 表都已经太细，
而你现在只想回答：

- `这组报表业务上到底在看什么`
- `Salesforce 现网主要在补什么语义`
- `CM 已经接住了什么`
- `当前更像 parity 还是 runtime`
- `最先打哪几个 front-door`

优先看这份。

如果要回到单张 front-door，
看：

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

如果要回到对象主链，
看：

- [salesforce-cm-bi-object-frontdoor-impact-index-2026-07-07.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-cm-bi-object-frontdoor-impact-index-2026-07-07.md)

如果要回到消费面证据强弱，
看：

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

## Summary Matrix

| 报表组 | 业务上实际在看什么 | Salesforce 现网主要在补什么 | CM 目前已支持什么 | CM 当前主要差异 / 风险点 | 对象主链 | 最先打哪几个 front-door | 当前证据强度 | 默认第一修复层 | 什么情况下才升级成 runtime |
|---|---|---|---|---|---|---|---|---|---|
| `Pipeline / Forecast / Opportunity Quality` | stage 卡点、forecast 分类、ARR/ACV、过期 close date、service-window 错位、长期未更新等质量问题 | 维护 `Opportunity` stage/forecast/probability、launch/close helper、owner-team，叠加 `Quote` service-window / nonstandard-term / cleanup | `Std_OpportunityStageDerivedFields`、`Opportunity_Cloud_Order_Type_Set`、`Opportunity_Close_Date_Auto_Set`、`Opportunity_Pricebook_Default`、`Quote_Reset_IsConvert_On_Submit`、`Quote_Account_Opportunity_field`、Quote validation substrate 已在；本地还已有 active `Add_or_update_Opt_Owner_s_Role`，会在 `RecordBeforeSave(CreateAndUpdate)` 把 `Owner.UserRole.Name` 写到 `Opt_Owner_Role__c`，形成 `owner_team` 的本地 peer substrate | `OpportunityShareToPersalesOwner*`、`Quote_update_nonstandard_conditions_checkbox*` 未补；quote/opportunity 邻近 validation 仍有 inactive；之后才是 `OpportunityTrigger` / `QuoteTrigger` | `Opportunity -> Quote`，次级 `Account` | `1733...` 主；`837...` 次级主面；`aadb...`、`0f2...`、`d916...` 次级 consumer | `1733...` / `837...` 是最硬的 live `report-backed` 面；其中 `1733...` 当前已能在 live BigQuery 里直接点到 `owner_team`、`stage_name`、`cloud_order_type`、`launch_date`、`stage_duration_days`。`aadb...` / `0f2...` / `d916...` 当前更像 `lineage-backed secondary consumer` | `L2 Opportunity/Quote parity` | 同面 exact-name parity 和 inactive validation 清完后，`owner_team` / quote cleanup 仍持续漂移 |
| `Lead Funnel / Qualification` | lead 如何到 `MQL`、`IQM`、建 opp、customer milestone；时间线和 lead/account/opportunity stitching 是否正确 | 维护 lead lifecycle、`lead_mql_timestamp`、`lead_iqm_timestamp`、status-change 时间戳、lead-account stitching、campaign path | `IQM_Completion_Flow`、`Lead_Status_Duration`、`Lead_Auto_Create_Org`、`BN_Lead_Relate_to_Account_by_Email_Domain_Flow`、`Std_ConvertLeadCampaignPreview` 已在 | `Lead_StatusChangeTimestamp` 语义过宽；Lead assignment / reminder / notification 长尾 parity 未清；之后才是 `LeadTrigger` / `LeadAITrigger` | `Lead -> Account / Opportunity`，次级 `CampaignMember` / `Contact` | `fd12...` 主；次级 `8c6f...` | `fd12...` 已 `report-backed`；模型与 live schema 也已坐实 | `Lead semantic narrowing + L2 parity` | lifecycle timestamp 语义收窄、Lead 长尾 parity 清完后仍稳定漂移 |
| `Campaign Attribution / ICP Analysis` | 哪些 campaign touch 真正贡献了 opp、ARR、ACV；ICP touch 是否在 IQM 前/建 opp 前影响 pipeline | 维护 `CampaignMember.first_responded_date`、response/involvement、lead-contact convert relink、contact/opportunity attribution | `Lead_Set_First_And_Last_CampaignMember*`、`Lead_Set_First_And_Last_CampaignMember_delete`、`Contact_Set_First_And_Last_CampaignMember*`、`Contact_Set_First_And_Last_CampaignMember_delete`、`Std_ConvertLeadCampaignPreview`、`Std_RelinkLeadChildren` 已在 | `Campaign_Member_Key_Message_Update` 未补；Contact live Flow peer 未见本地 peer；之后才是 `Trigger_CampaignMember` / Contact trigger residuals | `CampaignMember -> Contact -> Lead -> Opportunity` | `8c6f...` 主；`fd12...` 次级 | `8c6f...` 已 `report-backed`；当前这轮 live front-door 最硬的是直接命中 `dws_marketing.dws_campaign_attribution`，字段已复现到 `attributed_arr`、`campaign_id`、`campaign_name`、`contact_response_date`、`opportunity_contact_role`。更宽的 attribution datasource family 仍然围绕 `campaign_member/contact/lead/opportunity_contact_role` | `CampaignMember parity + Contact stitching parity` | `Campaign_Member_Key_Message_Update` 与 Contact stitching parity 清完后，response/involvement/attribution 仍持续漂移 |
| `Order / ARR / RevRec / Collections` | 服务期、current-month / historical-month ARR/MRR、revrec、回款、tenant 月度汇总、collections / payable 是否对得上 | 维护 order carry-over、revrec entity、PLG pool、collection helper、marketplace / org-to-collection bridge、line-item finance 语义 | `Order_Quote_Payment_Field_Inheritance`、`Cloud_Registration_Source_from_Org_to_Order`、`Order_Default_RevRec_Entity`、`Std_OrderActivateStamp`、`RevRec_Account`、`RevRec_Partner_Name`、Order 对 `Revenue__c` 的 rollup、IC helper 字段、line-item substrate 已在 | `Order_Org_Auto_Set_Account_*`、`Order_Set_PLG_BD_Pool`、`RevRec_Set_PLG_BD_Pool`、`Collection_*`、`Cloud_Registration_Source_from_Org_to_Collections` 未补；`Revenue__c.Name` / IC / line-item `Name` auto-number 未补；之后才是 finance runtime | `Order -> Revenue__c / Invoice_Collection__c / Order_Product__c`，次级 `Account` / `Org__c` | `837...`、`583...`、`f9c4...` | `837...` / `583...` / `f9c4...` 都已 `report-backed`；collections / revrec 细面仍部分偏 `direct-query spillover` | `L2 finance carry-over + revrec + collections parity` | 同面 carry-over / helper / auto-number parity 清完后，finance 指标仍持续漂移 |
| `Account / Tenant Linkage / Customer Identity` | account 挂了哪些 tenant、收入应累到哪个 tenant/account、shared segmentation / ICP / industry 维度是否串歪；以及 cloud tenant / billing owner / PLG funnel 这些桥接面有没有被 account 维度污染 | 维护 `Account_ID`、ICP、Segmentation、Industry、current-order-type、contract-valid、tenant/account shared dimension、org bridge | `Account_ID__c` autonumber、`Current_Order_Type__c`、`Contract_Valid_*` 字段 substrate 已在；`Org_Set_Account` 已在；本地还已有 active `Account_status_Flow`，会在 `NA + churn/inactive + IfAutoSetOwner__c = false` 这类条件下回写 `OwnerId` / `IfAutoSetOwner__c`。`salesforce_accounts` / `dim_org` / `dim_tenant` 链路也已在。repo 侧现在可以更硬地拆成 3 档：`current_order_type` 不只是进 tenant 主链，而是当前完整 repo 搜索已命中 `66` 个文件，覆盖 `tidbcloud`、`dbaas_billing`、`fp_and_a` 等多组下游模型；owner/shared-dimension 也不只停在 warehouse expose，`owner_user_id / sales_team_name` 当前命中 `12` 个文件，并进入 `dim_account.yml`、`salesforce_users.yml`、`dim_employee.sql`、`dws_opportunity_stage_duration.sql` 这组命名维表/下游模型；而 `contract_valid*` 当前仍只命中 `2` 个文件，停在 `stg_salesforce_account.sql` / completion-test preservation，命名 `salesforce_accounts.sql` 也没有把它投出来，而且 `warehouse/business_operations/schema/` 目录里没有 `salesforce_accounts.yml` | `Account_Current_Order_Type`、`Account_Partner_Sales_Owner_Set`、`Account_Contract_Valid_Message` 未补；邻近 `Order/Org` carry-over 也会回流污染这里；之后才是 `AccountTrigger` | `Account -> Org__c`，次级 `Order` / `Opportunity` | `583...`、`673...` / `212...`，dependent `690...`，次级 `00675...` / `1e22...` / `31605...` / `eae0...` / `aadb...` / `f9c4...` | `673...` / `212...` 当前已经能更硬地拆成 `account/user/user_role + forecast snapshot` 这组 account forecast family；`690...` 更像纯 `model_plg` funnel / billing-capable user 面，而且当前 strongest field snippets 是 `tenant_*` + funnel metric，不适合作为 account 主票；`00675...` / `eae0...` 更像 tenant ops 面；`1e22...` / `31605...` 更像 cloud billing owner/allocation 面，其中 `31605...` 已有本机标题证据 `Cloud Billing Breakdown Detail`。BigQuery labels 在 `report-backed` 查询里通常能给到 `report_id + datasource_id`，但这轮 `contract_valid*` 还补到一层只带 `requestor` 的 Looker Studio exploratory query，所以 title/owner metadata 仍不完整，也不能把所有 Looker Studio 痕迹都硬挂到命名 report_id | `L2 Account dimension / shared-key parity` | account exact-name parity 与 tenant bridge 邻近漂移清完后，shared dimension 仍持续漂移 |

## 默认优先级

1. `Lead Funnel / Qualification`
   先打 `fd12...`
2. `Pipeline / Forecast / Opportunity Quality`
   先打 `1733...`
3. `Order / ARR / RevRec / Collections`
   先打 `837...`，再看 `f9c4...`
4. `Campaign Attribution / ICP Analysis`
   先打 `8c6f...`
5. `Account / Tenant Linkage / Customer Identity`
   先打 `583...` / `673... / 212...`
   `690...` 默认作为 dependent consumer 回归面

## 一句话收口

`如果只剩一页给别人看，最稳的读法是：大多数报表组现在都更像“CM 已有 substrate，但 PingCAP L2 parity 还没补齐”；真正可以升级成 CM 真 gap 的，主要是同组 parity 清完后残留的 Lead、Opportunity/Quote、Finance 三类 runtime。`