# Salesforce / CM / BI Mechanism Matrix

Date: `2026-07-07`

## 用法

这份文档是
`机制视角`
。

适合回答这类问题：

- `某条 Salesforce 机制具体在维护什么业务语义`
- `CM 这边有没有邻近承接件`
- `当前缺的是 exact-name parity、semantic narrowing，还是 runtime residue`
- `它最先会打哪张报表 / 哪个 dbt 模型`

如果要先从报表面读，
看：

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

如果要先从对象面读，
看：

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

如果要直接看
`字段 / 指标`
，
看：

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

如果要看完整证据链，
看：

- [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)

## 总原则

| 读法 | 当前最稳结论 |
|---|---|
| 机制名出现在 live / 报告里，是不是就等于 `CM 真 gap` | `不是` |
| 当前最常见的机制差异 | `L2 exact-flow parity`、`semantic narrowing mismatch`、`activation-state mismatch` |
| 什么最接近 `CM 真边界` | parity 清完后仍只剩 `LeadTrigger / OpportunityTrigger / OrderTrigger / RevenueTrigger / Trigger_CampaignMember` 这类 runtime residue |
| 默认动作 | 先补 `PingCAP L2 pack parity`，再单列 residual runtime |

## Mechanism Matrix

| 机制 | Salesforce 现网主要在做什么 | CM 目前已支持什么 | CM 当前未支持 / 疑似未支持什么 | 差异类型 | 最先影响哪张报表 / dbt consumer |
|---|---|---|---|---|---|
| `Lead_StatusChangeTimestamp` | 只在 `Lead.Status` 进入 `working_or_later` 时写 lead lifecycle 时间戳，收窄 `status change` 语义 | 本地已有 `Lead_Status_Duration.flow.json`、`IQM_Completion_Flow.flow.json`、`Lead.json` 上的 lifecycle / IQM 字段；`lead_mql_timestamp`、`lead_iqm_timestamp` 主链已在 | 当前不是 `0 hits`，而是本地 `Lead_Status_Duration` 语义更宽；parity 清完后才看 `LeadTrigger` / `LeadAITrigger` | `semantic narrowing mismatch` | `fd12...`，次级 `salesforce_leads` / `dws_lead_timeline` / `dim_lead` / `dws_icp_summary` |
| `Campaign_Member_Key_Message_Update` | 维护 `CampaignMember` 的 response / involvement 邻近语义，使 `first_responded_date`、`contact_response_date`、attribution 输入稳定 | 本地已有 `Lead_Set_First_And_Last_CampaignMember`、`Contact_Set_First_And_Last_CampaignMember`、`Std_ConvertLeadCampaignPreview`；下游已真实算 `attributed_arr` / `attributed_acv` | 当前在本地 pack 与 final merged pack 中都是 `0 hits`；补完后再看 `Trigger_CampaignMember` / Contact trigger residue | `L2 exact-flow parity` | `8c6f...`，次级 `salesforce_campaign_members` / `dws_campaign_attribution` / `dws_campaign_attribution_details` / `fd12...` |
| `Quote_update_nonstandard_conditions_checkbox` | 维护 quote nonstandard-term / cleanup 商业语义，让 quote service-window 与 cleanup 面口径稳定 | 本地 Quote substrate 已在：`Quote.json` 有 `Service_Start_Date__c`、`Service_End_Date__c`、`QuoteNumber`、`Governing_Service_*`、`Migration_Credit_is_nonstandard__c`、`Other_Nonstandard_Terms_and_Conditions__c`；approval 备份已直接引用 nonstandard-term 字段；quote 邻近 Flow / validation 已存在，而且 Order governing-contract validation 还会继续消费这组 service-window | 当前 exact-name Flow 在本地 pack 与 final merged pack 中 `0 hits`；同时还有 3 条 live active / local inactive quote validation | `L2 exact-flow parity` + `activation-state mismatch` | `1733...`，次级 `salesforce_opportunities` / `dim_opportunity` / `dws_salesforce_arr_summary` |
| `Quote_update_nonstandard_conditions_checkbox_2` | 同组 quote nonstandard / cleanup 补齐腿，保持 quote commercial helper 连续正确 | 同上；当前更稳的读法是“缺 cleanup / auto-check Flow”，不是“本地没有 nonstandard-term 字段或 approval substrate” | 当前 exact-name Flow `0 hits`；与上一条同组处理 | `L2 exact-flow parity` + `activation-state mismatch` | `1733...`，次级 `salesforce_opportunities` / `dim_opportunity` |
| `OpportunityShareToPersalesOwner` | 在 opportunity create 后维护 presales-owner share / owner-team 邻近语义，保证 DQ / owner-team 口径稳定 | 本地已有 `Std_OpportunityStageDerivedFields`、`Opportunity_Cloud_Order_Type_Set`、`Opportunity_Close_Date_Auto_Set`；active `Add_or_update_Opt_Owner_s_Role` 还会在 `RecordBeforeSave(CreateAndUpdate)` 把 `Owner.UserRole.Name` 写到 `Opt_Owner_Role__c`，形成本地 owner-role peer；`salesforce_opportunities` 已真实消费 `owner_team`、`cloud_order_type`、`stage_name` | 当前 exact-name create-flow 在本地未见 peer；补完后仍可能剩 `OpportunityTrigger` residue | `L2 exact-flow parity` | `1733...`，次级 `dws_data_quality_alerting` / `rpt_data_quality_wtw_comparison` / `anls_business_operations.dim_opportunity` |
| `OpportunityUpdateShareToPerSalOwner` | 在 opportunity update 后维持同组 owner-share / owner-team 语义，防止更新后口径漂移 | 同上 | 当前 exact-name update-flow 在本地未见 peer；这是高置信 sibling，但不要和 create 腿混读 | `L2 exact-flow parity` | `1733...`，次级 `dws_data_quality_alerting` / `anls_business_operations.dim_opportunity` |
| `Account_Current_Order_Type` | 在 `Account` 侧持续维护 `account_current_order_type`，把 account、tenant、current-month MRRARR、finance/account bridge 面维持同一口径 | 本地 `Account.json` 已有 `Current_Order_Type__c`；`Org_Set_Account` 已在；下游已真实消费 `account_current_order_type` | 当前 tree 里 exact-name Flow `0 hits`；并且历史 evidence 还暴露过 `FlowVersionId ... not accessible` 的 dispatch/accessibility 风险 | `L2 exact-flow parity` + `dispatch/accessibility risk` | `583...` 主，`690...` 次级 consumer，front-door direct hit 更强的是 `f9c4...` / `31605...` 这类 tenant/account bridge 面 |
| `Account_Partner_Sales_Owner_Set` | 维护 account owner / shared dimension 邻近语义，使 account forecast / governance 面稳定 | 本地 account dimension substrate、`Account_ID__c`、`Org_Set_Account` 均已在；active `Account_status_Flow` 还会在特定本地条件下回写 `OwnerId` / `IfAutoSetOwner__c`，形成部分 owner peer | 当前 exact-name Flow `0 hits`；但更像 shared-dimension parity，不宜先升 runtime | `L2 exact-flow parity` | `673... / 212...` 主，`583...` 次级；命名模型链包括 `salesforce_accounts` / `salesforce_users` / forecast owner 模型 |
| `Account_Contract_Valid_Message` | 在 account 侧维护 contract-health reminder / warning 语义，使 contract-valid governance 在 account 维度可见 | 本地 `Account.json` 已有 `Contract_Valid_Date__c`、`Contract_Valid_Days__c`、`Contract_Valid__c`；layout 也已把这些字段露出 | 当前 `Account_Contract_Valid_Message` / `_1` 在本地未见 peer；contract 侧也仍缺 `Contract_Update_Account_Contract_Valid`。warehouse/modeling consumer 已存在，但当前 account front-door 仍未把 `contract_valid*` 打成 direct field hit | `L2 governance parity` | `673... / 212...` 主，次级 `crm_account` / `salesforce_accounts` / `dim_account` / `dim_tenant` |
| `Order_Org_Auto_Set_Account_Create` | 在 order create 时补齐 order、org、account、tenant 的 carry-over，避免 finance 事实与 tenant/account bridge 断开 | 本地已有 `Org_Set_Account`、`Cloud_Registration_Source_from_Org_to_Order`、`Order_Default_RevRec_Entity`；`Order.json` 也已有 bridge / finance 字段 | 当前 exact-name Flow `0 hits`；补完前会把 account/tenant 对齐和 current-month finance 一起打歪 | `L2 finance carry-over parity` | `583...`、`837...`、`f9c4...`，次级 `salesforce_order_daily_view` / `salesforce_org_monthly_revrec` / `cp_order_monthly_revrec` |
| `Order_Org_Auto_Set_Account_Update` | 在 order update 后持续维持同组 carry-over 关系，防止 update 后 finance / tenant bridge 漂 | 同上 | 当前 exact-name Flow `0 hits` | `L2 finance carry-over parity` | `583...`、`837...`、`f9c4...`，次级 `salesforce_order_daily_view` / `salesforce_org_monthly_revrec` |
| `Order_Set_PLG_BD_Pool` | 在 order 侧维护 PLG pool / finance segmentation，使 ARR / MRR / collections 口径按 pool 分群稳定 | 本地 `Order.json`、`Invoice_Collection__c.json`、`Revenue__c.json` 都已有邻近 pool 字段 / finance substrate | 当前 exact-name Flow `0 hits`；清完同组 carry-over 后再看 `OrderTrigger` residue | `L2 finance carry-over parity` | `837...`、`583...`、`f9c4...`，次级 `salesforce_orders` / `dws_salesforce_arr_summary` |
| `RevRec_Set_PLG_BD_Pool` | 在 revenue / revrec 侧维护 PLG pool，使 recognized/deferred revenue 和 ARR bridge 保持分群一致 | 本地 `Revenue__c.json` 已有 `PLG_BD_Pool__c`；`Order` 侧已有 revenue rollup；`Order_Default_RevRec_Entity` 已在 | 当前 exact-name Flow `0 hits`；`Revenue__c.Name` 也仍未补；再往后才是 `RevenueTrigger` | `L2 revrec parity` | `837...`，次级 `f9c4...` / `salesforce_revrec` / `salesforce_orders.revenues` / `monthly_revrec_orders` |
| `Collection_Set_PLG_BD_Pool` | 在 `Invoice_Collection__c` 侧维护 pool carry-over，使 collections / payable / revrec 校验按 pool 对齐 | 本地 `Invoice_Collection__c.json` 已有 `PLG_BD_Pool__c`、helper 字段；`Order` 侧也已有 collections 汇总 | 当前 exact-name Flow `0 hits` | `L2 collections parity` | `f9c4...`，次级 `salesforce_order_daily_view` / `monthly_revrec_collections` |
| `Collection_Amount_and_Payable_Amount_exc_tax` | 在 collection create 腿维护 exc-tax helper / payable / collections amount 语义 | 本地 `Invoice_Collection__c.json` 已有 `Collections_Amount_exc_tax__c`、`Payable_Amount_USD2_exc_tax__c`、`Cash_Collected__c` 等 helper 字段 | 当前 exact-name create-flow `0 hits` | `L2 collections parity` | `f9c4...`，次级 `salesforce_order_daily_view` / `salesforce_org_monthly_revrec` |
| `Collection_Amount_and_Payable_Amount_exc_tax_Update` | 在 collection update 腿持续维持 exc-tax helper 正确，防止 update 后 payable / collected timing 漂移 | 同上 | 当前 exact-name update-flow `0 hits` | `L2 collections parity` | `f9c4...`，次级 `salesforce_order_daily_view` / `salesforce_org_monthly_revrec` |
| `Cloud_Registration_Source_from_Org_to_Collections` | 把 `Org__c` 上的 cloud-registration / marketplace carry-over 到 collections 侧，保证 tenant / marketplace attribution 正确 | 本地已有 `Cloud_Registration_Source_from_Org_to_Order` 这条 order peer；`Org__c` / `Order` substrate 已在 | 当前 collections 腿 exact-name Flow `0 hits` | `L2 finance carry-over parity` | `f9c4...`，次级 `690...` / `salesforce_org_monthly_revrec` / `stg_salesforce_invoice_collection` |
| `Auto_Expire_Contract` | 维护 contract 到期状态，支撑 contract-valid / governing-contract 邻近语义 | 本地已有 `ContractNumber`、`Contract_Archived_Status_Autopromote`、`Std_ContractActivateStamp`，以及 `Account` 上的 `Contract_Valid_*` 基座 | 当前 exact-name Flow 在本地未见；但这条要和 PingCAP 本地 governing-contract replacement policy 分开看 | `L2 contract governance parity` + residual runtime | `salesforce_orders` / `salesforce_order_daily_view` / `dws_salesforce_arr_summary`，次级 account governance 面 |
| `Contract_Update_Account_Contract_Valid` | 在 contract 变化后回写 / 刷新 account contract-valid 状态 | 本地 account contract-valid 字段已在 | 当前 exact-name Flow 在本地未见；与 `Account_Contract_Valid_Message` 同组更像 account-governance 提示链缺口 | `L2 governance parity` | `673... / 212...`，次级 `salesforce_accounts` / `dim_account` / `dim_tenant` |

## 机制优先级

| 优先级 | 机制 | 为什么先做 |
|---|---|---|
| `P1` | `Lead_StatusChangeTimestamp` | 它不是空白能力，而是最清楚、最可落地的 semantic narrowing 收口点，直接影响 `fd12...` |
| `P1` | `Campaign_Member_Key_Message_Update` | 当前 attribution 面最短板最集中的一条 exact-name Flow |
| `P1` | `Quote_update_nonstandard_conditions_checkbox` / `_2` | 是 `1733...` cleanup / quote commercial 语义最直接的 exact gap |
| `P1` | `OpportunityShareToPersalesOwner` / `OpportunityUpdateShareToPerSalOwner` | owner-team / DQ 面报表近邻缺口，证据清楚 |
| `P1` | `Account_Current_Order_Type` | 共享维度主轴，同时还带 dispatch/accessibility 风险 |
| `P1` | `Order_Org_Auto_Set_Account_Create` / `_Update` | 这是 account/org/order carry-over 主链，会同时打 account bridge 和 finance truth |
| `P1` | `Order_Set_PLG_BD_Pool` | 是 ARR / MRR / collections segmentation 的 shared mechanism |
| `P1` | `Collection_Set_PLG_BD_Pool` | collections 面最直接的 pool 漂移点 |
| `P1` | `Collection_Amount_and_Payable_Amount_exc_tax` / `_Update` | 直接决定 payable / collections / exc-tax helper correctness |
| `P1` | `Cloud_Registration_Source_from_Org_to_Collections` | 会把 marketplace / tenant attribution 一起打歪 |
| `P1` | `RevRec_Set_PLG_BD_Pool` | revrec 侧最明确的一条 single-name finance exact gap |
| `P2` | `Account_Partner_Sales_Owner_Set` | 重要，但通常次于 `Account_Current_Order_Type` 的 shared-dimension blast radius |
| `P2` | `Account_Contract_Valid_Message` | 更偏 account-governance / forecast，优先级低于 current MRRARR / tenant bridge 主链 |
| `P2` | `Auto_Expire_Contract` / `Contract_Update_Account_Contract_Valid` | 要继续和 PingCAP 本地 governing-contract replacement policy 分开看 |

## 一句话收口

`机制层当前最常见的不是 CM 没有能力，而是 exact-name Flow / narrowing / carry-over 这层 parity 还没补齐；真正更像 CM 真边界的，要等这些机制补完后剩下的 trigger/runtime 残余。`