# Salesforce / CM / BI 一页对齐稿

Date: `2026-07-07`

如果你现在最关心的是
`CM 创建出来的对象，和 Salesforce 创建出来的对象相比，哪些业务字段会没值/值不同`
，
直接看：

- [salesforce-cm-create-field-value-gap-matrix-2026-07-07.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-cm-create-field-value-gap-matrix-2026-07-07.md)
- [salesforce-cm-core-object-field-gap-catalog-2026-07-08.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-cm-core-object-field-gap-catalog-2026-07-08.md)

## 一句话结论

当前看到的大多数 gap，不是 `CM 平台完全没能力`，而是：

- CM substrate 已经有
- PingCAP final pack 还没完全补齐 live Salesforce 的 Flow / auto-number /
  validation 激活态

真正更像平台边界的，主要还是：

- 仍只活在 live Salesforce `Apex trigger` 里的逻辑

所以这份报告更准确的读法是：

- 它是 `Salesforce live 行为 vs CM 当前落地状态` 的差异清单
- 不是一张“所有项都等于 CM 能力缺口”的列表

最稳的进一步说法是：

- `activation-state mismatch` 不等于 `CM 没能力`
- `exact named missing mechanisms` 多数也不等于 `CM 没能力`
- `runtime boundary` 才最接近 `CM 目前真没支持`

如果只从
`字段有没有值`
这个角度看，
当前最重的对象顺序更接近：

1. `Account`
2. `Order`
3. `Revenue__c`
4. `Invoice_Collection__c`
5. `Quote`
6. `CampaignMember`

## 如果改看整体报表爆炸半径

这一段不是
`字段有没有值`
的优先级，
而是
`如果从整体报表爆炸半径和自动化密度来排`
，
优先级大致是：

1. `Opportunity`
2. `Lead`
3. `Order`
4. `Account / Org__c`
5. `CampaignMember`
6. `Revenue__c`
7. `Invoice_Collection__c`

## Salesforce 现在还在帮我们做什么

对这些核心对象，Salesforce 还在自动维护：

- auto-number
- formula / rollup / derived 字段
- validation rules
- record-triggered / scheduled Flows
- Apex triggers

所以“记录能创建出来”不等于“记录已经具备报表语义”。

## CM 目前已经支持什么

当前仓库证据表明，CM 已经具备并在 PingCAP pack 中实际使用了：

- formula fields
- validation rules
- rollup summaries
- record-triggered Flow substrate
- 部分 auto-number

finance 这条线里，本地 `Order` 也已经明确承接了几块关键语义：

- `Quote -> Order` 核心字段继承
- payment field inheritance
- `Order_Default_RevRec_Entity`
- account-level governing-contract validation replacement policy

所以这不是“CM 什么都没有”的问题。

## 现在最值得区分的三类 gap

这里的 `gap` 只是差异，不自动等于 `CM 做不到`。

### 1. `activation-state mismatch`

定义已经在 pack 里，但 live 是 active、本地是 inactive。

当前最明确的是：

- `Lead.Nurture_Marketing_Date`
- `Lead.Nurture_Sales_Date`
- `Opportunity.PingCAP_Contract_Entity_EMEA_only`
- `Quote.Customer_s_Hardware_Configuration`
- `Quote.Details_of_vCPU_Calculation`
- `Quote.Version_of_TiDB`

这类不是“缺定义”，更像“该激活的还没激活”。

### 2. `exact named missing mechanisms`

名字已经拿到，可以直接补。

高价值例子：

- `Account_Contract_Valid_Message`
- `Account_Current_Order_Type`
- `Order_Org_Auto_Set_Account_Create`
- `Order_Set_PLG_BD_Pool`
- `Campaign_Member_Key_Message_Update`
- `RevRec_Set_PLG_BD_Pool`
- `Collection_Set_PLG_BD_Pool`
- `Collection_Amount_and_Payable_Amount_exc_tax`
- `Collection_Amount_and_Payable_Amount_exc_tax_Update`
- `Cloud_Registration_Source_from_Org_to_Collections`
- `Revenue__c.Name`
- `Invoice_Collection__c.Name`
- `Opportunity_Product__c.Name`
- `Order_Product__c.Name`
- `Quote_Product__c.Name`

但这里要单独排除一类容易误判的项：

- `Order_Create_Requires_Effective_CSA_MA_Contract`

按当前仓库证据，它更像已被 PingCAP 本地 governing-contract policy
替代的 Salesforce-era 旧规则名，不该直接算成 `CM 平台不会做`。

### 3. `runtime boundary`

仍只活在 live Apex trigger 里的逻辑。

高风险对象：

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

## 对哪张报表最敏感

### Pipeline / Forecast

先看：

- `salesforce_oppo`
- `salesforce_opportunities`
- `dws_salesforce_arr_summary`
- `dws_opportunity_stage_duration`

最先查：

- `Opportunity`
- `Quote`

### Lead Funnel / Qualification

先看：

- `salesforce_lead`
- `salesforce_leads`
- `dim_lead`
- `dws_lead_timeline`

最先查：

- `Lead`
- `CampaignMember`

### Order / ARR / RevRec / Collections

先看：

- `salesforce_orders`
- `salesforce_order_daily_view`
- `cp_order_monthly_revrec`
- `salesforce_revrec`
- `salesforce_org_monthly_revrec`

最先查：

- `Order`
- `Revenue__c`
- `Invoice_Collection__c`
- current `Invoice_Collection__c` exact-name backlog now includes
  `Collection_Set_PLG_BD_Pool`,
  `Collection_Amount_and_Payable_Amount_exc_tax`,
  `Collection_Amount_and_Payable_Amount_exc_tax_Update`,
  and
  `Cloud_Registration_Source_from_Org_to_Collections`
- but current checked-out BI evidence is strongest at
  `stg_salesforce_invoice_collection`
  plus recurring finance outputs; do not overstate that current
  `salesforce_orders.sql`
  already joins all IC detail into the final mart

- `Order`
- `Revenue__c`
- `Invoice_Collection__c`

这里再补一个优先级判断：

- 如果目标是先止住 `gcp-digital-bi` finance 指标漂移，
  先看 `CollectionsStatus / carry-over / PLG pool / invoice-status`
  这类 Flow parity
- `Revenue__c.Name`、`Invoice_Collection__c.Name` 这种 auto-number 也该补，
  但按当前仓库证据，它们的 BI 直接爆炸半径低于前面这组

### Account / Tenant Linkage

先看：

- `crm_account`
- `salesforce_accounts`
- `salesforce_orgs`
- `dim_tenant`
- `customer_surrogate_keys`

最先查：

- `Account`
- `Org__c`
- order carry-over fields

## 按报表组说人话

如果不想按对象讲，可以直接按下面 5 组报表讲：

| 报表组 | 业务上在看什么 | CM 当前判断 |
|---|---|---|
| `Lead Funnel / Qualification` | lead 怎么走到 `MQL`、`IQM`、建机会、变客户 | 不是平台空白，主要是 Lead Flow 还没补齐，外加少量 validation 激活态没对齐 |
| `Pipeline / Forecast / Opportunity Quality` | 机会 stage、forecast、ARR/ACV、close/launch、质量异常 | 这是当前最值得先修的一组；Opportunity/Quote 语义很重，缺口仍以 Flow parity 和少量 inactive validation 为主 |
| `Campaign Attribution / ICP Analysis` | 哪些 campaign touch 真正贡献了 pipeline / ARR / ACV | 指标语义已经很明确，最直接的缺口是 `Campaign_Member_Key_Message_Update` 和残余 trigger 边界 |
| `Order / ARR / RevRec / Collections` | 服务期、收入确认、累计收入、回款、tenant 汇总是否正确 | 这组 operational evidence 很强；Order / Revenue / Invoice_Collection 仍有缺失 Flow、auto-number 和部分 trigger/runtime 边界，但对 BI 爆炸半径最大的仍是状态切换 / carry-over Flow，不是 `Name` auto-number 本身 |
| `Account / Tenant Linkage / Customer Identity` | 一个 account 对应哪些 tenant，收入该累到哪边，主数据维度是否一致 | 主链路已存在，但 Account 缺失 Flow 和 Order/Revenue carry-over 缺口会把共享维表打歪 |

一句话优先级：

1. `Pipeline / Forecast / Opportunity Quality`
2. `Lead Funnel / Qualification`
3. `Order / ARR / RevRec / Collections`

原因不是这三组“CM 最没能力”，而是：

- 报表爆炸半径最大
- 当前证据最强
- 高置信修复项最多，很多先补 `L2 pack` 就能开始收敛

如果要继续往下问
`CM 具体已经有哪几个 Flow / validation / auto-number，缺的又是哪几个`
，
现在主报告里已经有一层
`Report-Group Mechanism Map`
可以直接回答，不用再回到纯对象矩阵里拆。

如果还要继续问
`这些机制在仓库里具体去哪看`
，
主报告现在也有
`Repo File Quick Index`
，
可以直接按报表组跳到本地 `flows/`、`objects/`、`validation/`、
`autonumber/` 文件。

## 目前拿到的显式消费面证据

- repo 里目前明确写出来的 dashboard，只有一个：
  `Opportunity Data Quality Monitoring`
- owner 也明确在 dbt exposure 里：
  `Chen Du <chen.du@pingcap.com>`
- clone 下来的 `digital-bi-dbt` checkout 里，目前也只有这一份
  `exposures.yml`
- clone 下来的 `looker-schema` checkout 里，没有额外的 CRM
  `.dashboard.lookml`
  文件
- 当前 checked-out Looker repo 里，CRM 相关的直接 Explore 入口也只有 3 个：
  `crm_account`、`salesforce_oppo`、`cloud-lead-pipeline-insight` 里的
  `salesforce_lead`
- `Lead Funnel / Qualification`、`Campaign Attribution / ICP Analysis`、
  `Order / ARR / RevRec / Collections` 这些组，当前更多还是靠
  `Looker Explore 名字 + dbt mart lineage`
  来定位影响面
- 但 `finance` 这条线现在已经比 marketing 多出一层 repo 外证据：
  `pingcap-datalake` 里有
  `monthly_revrec_orders` /
  `monthly_revrec_collections`
  的 curated contract、freshness、blocking tests、declared lineage 和
  orchestration 说明；`netforce-hub` 里也有直接查这些 revrec 表的代码
- 而且在 `digital-bi-dbt` 自己的 finance 目录里，
  `monthly_cloud_revrec/sources.yml`
  已经把
  `monthly_revrec_orders`
  /
  `monthly_revrec_collections`
  定义成 source，
  `monthly_cloud_billing_revrec.py`
  还会直接从
  `salesforce_org_monthly_revrec`
  和
  `salesforce_order_daily_view`
  读数据并写回这些 output 表

所以现在更准确的说法是：

- marketing 当前更像
  `mart/explore semantics 证据强，dashboard/owner 证据弱`
- finance 当前更像
  `mart + source contract + recurring output 证据都强`

marketing 这边虽然缺 dashboard/owner 清单，但 SQL 因果链已经很实：

- `salesforce_campaign_members.sql`
  会把 `campaign_member_status` 映射成
  `is_contact_involved` / `contact_involvement_level`
  ，并在缺 `first_responded_date` 时做回填
- `salesforce_campaign_attributions.sql`
  会把 campaign contact 权重归一成 `attribution_percentage`
- `dws_campaign_attribution.sql`
  再把它乘到 `accurate_acv_amount` / `arr_amount_usd`
  上，产出 `attributed_acv` / `attributed_arr`
- `dws_lead_timeline.sql`
  直接把 `lead_mql_timestamp`、`lead_iqm_timestamp`、
  `Opportunity.created_timestamp`、`launch_date`、
  `CampaignMember.first_responded_date`
  变成事件线
- `dws_icp_summary.sql`
  再把这些事件和 account segmentation、opp ARR/ACV/stage 串起来

对象级别也已经能讲得更细：

- `Lead`
  现在最关键的是
  `lead_mql_timestamp` / `lead_iqm_timestamp`
  、lifecycle、account/tenant 关联
- `Opportunity`
  现在最关键的是
  `forecast_category`、`forecast_type`、`owner_team`、
  `stage_duration_days`、`launch_date`、
  `accurate_acv_amount` / `arr_amount_usd`、
  以及 quote enrichment 字段
- `CampaignMember`
  现在最关键的是
  `campaign_member_status`、
  `first_responded_date`、
  `contact_involvement_level`、
  `attribution_percentage`
  这条归因链

- `哪类报表 / 哪组模型会受影响`

但还不能说我们已经拿到了：

- `完整 dashboard / owner 清单`

## 最务实的执行顺序

1. 激活已经存在但 inactive 的 validation
2. 补已知名字的 L2 Flows
3. 补缺失 auto-number
4. 继续把还没拿全名字的 Flow 补成完整 backlog
5. 最后单独拆 Apex/runtime 替代工作

## 注意事项

- `Order_Activate_Contract_*` 那组 inactive rule 目前更像
  `intentional replacement`
  而不是普通 drift
- `packs/AUTO_GEN_Product-pack/live/flow_definitions/flow_definitions.json`
  只是 filtered live export slice，不能替代完整 live Flow inventory

## 详细报告

See:

- [salesforce-cm-bi-final-conclusion-2026-07-07.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-cm-bi-final-conclusion-2026-07-07.md)
- [salesforce-common-object-create-automation-audit-2026-07-07.md](/Users/amber/ai/nexuscrm-pingcap-pack/docs/salesforce-common-object-create-automation-audit-2026-07-07.md)