# Salesforce / CM / BI Verdict Register

Date: `2026-07-07`

## 用法

这份文档是
`最后判词版`
。

它不再按
`报表`
、
`对象`
、
`机制`
、
`字段`
来展开，
而是直接回答：

- `这个名字到底算不算 CM 真 gap`
- `如果不算，更准确该怎么叫`
- `最先会打哪张报表`

适合在讨论时快速止住下面这类误读：

- `报告里列到它了，所以 CM 一定做不到`
- `有个 exact-name 缺口，所以平台一定没能力`
- `看见 trigger 就等于所有邻近 parity 都不用补`

如果当前更想先看
`哪些才算真能力边界`
，
先看：

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

## 判词规则

| 判词 | 现在怎么读 |
|---|---|
| `已支持 / 已回归覆盖` | 当前不该再算 gap；更像已支持机制的稳定性或回归验证对象 |
| `semantic mismatch` | 本地已有近似承接，但语义条件和 live 不完全相同 |
| `activation-state mismatch` | 定义已在本地，只是 live active / local inactive |
| `L2 exact-flow parity` | CM 已有 substrate，但 PingCAP L2 还没把 exact-name Flow/规则补齐 |
| `L2 finance carry-over parity` | 本地 bridge / helper / rollup 已在，但 finance 侧某一腿未补齐 |
| `auto-number parity missing` | 更像 metadata parity，不是 substrate 空白 |
| `intentional replacement` | 当前更像 PingCAP 本地 policy 替代，不该默认回补 Salesforce 原语义 |
| `runtime boundary` | 这才更接近 `CM 目前真没支持` |
| `runtime boundary candidate` | 先清完同面 parity，再决定是不是 runtime 真边界 |

## Verdict Register

| 典型项 | Salesforce 现网主要在做什么 | CM 目前已支持什么 | 当前最稳判词 | 是否应直接说成 `CM 目前做不到` | 最先影响哪组报表 |
|---|---|---|---|---|---|
| `Lead_Assignment_Rule_modification_for_NA_EMEA` | 按 `Company/Region/AccountStatus` 路由 Lead owner/SDR，并回写部分 assignment 邻近字段 | 本地已登记同名 Flow，且 staging regression 用例已通过 | `已支持 / 已回归覆盖` | `否` | `操作面优先`；间接影响 lead owner / SDR，当前不是 BI 主轴 |
| `Lead_StatusChangeTimestamp` | 只在 status 进入特定 lifecycle 语义时写时间戳 | 本地已有 `Lead_Status_Duration`、`IQM_Completion_Flow` 等邻近承接件；当前 `Salesforce-PingCAP-L2` pack 对 exact-name `0 hit` | `semantic mismatch` | `否` | `fd12...`，次级 `salesforce_leads` / `dws_lead_timeline` / `dws_icp_summary` |
| `Lead.Nurture_Marketing_Date` / `Lead.Nurture_Sales_Date` | 维护 nurture 邻近治理语义 | 定义已在本地 | `activation-state mismatch` | `否` | `salesforce_leads` / `dim_lead` / `dws_lead_timeline` |
| `Campaign_Member_Key_Message_Update` | 维护 `CampaignMember` 的 response / involvement / attribution 输入稳定性 | 本地已有 first/last-touch 体系、`convertLead` attribution preview、以及 `Std_RelinkLeadChildren` 这条 converted Lead -> Contact 的 child relink。当前 exact-name 在 `Salesforce-PingCAP-L2` pack `0 hit` | `L2 exact-flow parity` | `否` | `8c6f...`，次级 `fd12...` |
| `Quote_update_nonstandard_conditions_checkbox` / `_2` | 维护 Quote nonstandard-term / cleanup / commercial helper 语义 | Quote 字段、validation 邻近件都在；更具体地说，本地 `Quote.json` 已有 `Service_Start_Date__c` / `Service_End_Date__c`、`Governing_Service_*`、`Migration_Credit_is_nonstandard__c`、`Other_Nonstandard_Terms_and_Conditions__c`，approval 备份也已直接引用 nonstandard-term 字段；两条 exact-name Flow 当前在 `Salesforce-PingCAP-L2` pack 都是 `0 hit` | `L2 exact-flow parity` | `否` | `1733...` pipeline data quality / cleanup |
| `OpportunityShareToPersalesOwner` / `OpportunityUpdateShareToPerSalOwner` | 维护 opportunity owner-team / presales-share 邻近语义 | 本地已有 `Opportunity` stage/forecast/close-date/cloud-order-type substrate；而且 active `Add_or_update_Opt_Owner_s_Role` 已会在 `RecordBeforeSave(CreateAndUpdate)` 把 `Owner.UserRole.Name` 回写到 `Opt_Owner_Role__c`。两条 exact-name Flow 当前在 `Salesforce-PingCAP-L2` pack 都是 `0 hit` | `L2 exact-flow parity` | `否` | `1733...`，次级 `dws_data_quality_alerting` / `dim_opportunity` |
| `Opportunity.PingCAP_Contract_Entity_EMEA_only` + 3 条 Quote validation | 维护 quote/opportunity commercial validation 语义 | 定义已在本地；当前确认是 `PingCAP_Contract_Entity_EMEA_only`、`Customer_s_Hardware_Configuration`、`Details_of_vCPU_Calculation`、`Version_of_TiDB` 这 4 条 rule 均存在但 `active = false` | `activation-state mismatch` | `否` | `1733...`、`salesforce_opportunities`、`dws_salesforce_arr_summary` |
| `Account_Current_Order_Type` | 在 `Account` 侧持续维护 current-order-type 维度 | `Account.Current_Order_Type__c` 字段已在，本地 account/org shared-key substrate 也在；exact-name Flow 当前 `0 hit`。repo 侧更进一步，`dbt-dev` 已把它明确带进命名 tenant 模型链：`dwd_cloud_tenant_middle_table.sql -> dwm_cloud_tenants.sql -> dws_cloud_tenants_basicinfo.sql` | `L2 exact-flow parity` | `否` | 直接命中当前 live query 的是 `31605...`、`f9c4...`；邻近 account/order 复合面还有 `583...`、`690...` |
| `Account_Partner_Sales_Owner_Set` | 维护 account owner / shared dimension 邻近语义 | 本地 account dimension substrate 已在，而且 active `Account_status_Flow` 已会回写 `OwnerId` / `IfAutoSetOwner__c`；但它的覆盖范围是明显收窄的：当前实现会按 `Username = kevin.lu@pingcap.com` 去查目标 `User`，并且只在 `Region__c = 'NA'`、`IfAutoSetOwner__c = false` 且 account 进入 `Churn / Inactive` 这类状态分支时回写 owner。也就是说它更像一个本地 NA-status reassignment peer，而不是 `Account_Partner_Sales_Owner_Set` 的通用替代。字段面也能看出这条仍是 parity 而不是 substrate 空白：本地 `Account.json` 目前只有 `Partner_Sales_Email__c`，并没有 `Partner_Sales_Owner__c` peer，而 `Lead.json` 仍有 `Partner_Sales_Owner__c`。repo 侧已进入命名模型链：`salesforce_accounts.sql` 直接投影 `owner_id AS owner_user_id` / `tam_name`，`salesforce_users.sql` 还把 `user_role_name` 归一成 `sales_team_name`，而 pipeline/forecast 命名模型 `dwm_salesforce_pipeline_forecast_detail_v2.sql` 已直接带 `owner_id / owner_name / owner_email / account_segmentation / account_industry` | `L2 exact-flow parity` | `否` | 直接命中当前 live query 的是 `673...`、`212...`；邻近 owner/allocation 面还有 `1e22...` |
| `Account_Contract_Valid_Message` / `_1` | 维护 account contract-health reminder / governance 提示链 | 本地 `Contract_Number__c`、`Contract_Valid_Date__c`、`Contract_Valid_Days__c`、`Contract_Valid__c` 基础字段已在；两条 exact-name Flow 当前 `0 hit` | `L2 governance parity` | `否` | 当前 account front-door live query 里暂未看到 `contract_valid*` 直接命中；但它并不是没人用，live BigQuery 里已有 `nexuscrm_final.nexuscrm_account` / `salesforce.account` 的 warehouse-modeling consumer。再往前只补到一层更弱的 BI 证据：`2026-01-14 11:30:26` `chen.du@pingcap.com` 有一批 `requestor = looker_studio` 的 `salesforce.account` 字段探索，直接扫到 `contract_valid*`；而且同一秒是 `51` 条、`51` 个 distinct query，更像 datasource/schema exploration burst，但没有 `report_id` / `datasource_id` label，所以仍不该升格成已坐实的 report-backed front-door。repo 侧也只补到 staging/schema 保真：当前完整 repo 搜索里，`contract_valid` 在 `dbt-dev + digital-bi-dbt` 总共只命中 `2` 个文件，即 `stg_salesforce_account.sql` 与 completion test；命名 `salesforce_accounts.sql` 当前并未投影这些字段，而且 `warehouse/business_operations/schema/` 目录里也没有 `salesforce_accounts.yml`。反过来 `account_current_order_type` 已命中 `66` 个文件，而 owner 维度 `owner_user_id / sales_team_name` 也命中 `12` 个文件并进入 `dim_account.yml` / `salesforce_users.yml` 等正式列声明，所以这两条 account gap 不该讲成同一档 severity |
| `Order_Org_Auto_Set_Account_Create` / `_Update` | 把 order、org、account、tenant carry-over 关系补齐 | 本地已有 `Org_Set_Account`、`Cloud_Registration_Source_from_Org_to_Order`、`Order_Default_RevRec_Entity`；两条 exact-name Flow 当前 `0 hit` | `L2 finance carry-over parity` | `否` | `583...`、`837...`、`f9c4...` |
| `Order_Set_PLG_BD_Pool` | 在 order 侧维护 PLG pool / finance segmentation | 本地已有 order/revenue/collection 邻近 pool substrate；exact-name Flow 当前 `0 hit` | `L2 finance carry-over parity` | `否` | `837...`、`583...`、`f9c4...` |
| `Collection_Set_PLG_BD_Pool` | 在 collection 侧维护 pool carry-over | 本地已有 `Invoice_Collection__c` helper 字段与 `Order` 侧 collections rollup；exact-name Flow 当前 `0 hit` | `L2 finance carry-over parity` | `否` | `f9c4...`，次级 `salesforce_order_daily_view` / `monthly_revrec_collections` |
| `Collection_Amount_and_Payable_Amount_exc_tax` / `_Update` | 维护 collection exc-tax helper / payable / collections amount 语义 | 本地已有 helper 字段与 Order 侧 payable/collections 汇总；两条 exact-name Flow 当前 `0 hit` | `L2 finance carry-over parity` | `否` | `f9c4...`，次级 `salesforce_order_daily_view` / `salesforce_org_monthly_revrec` |
| `Cloud_Registration_Source_from_Org_to_Collections` | 把 org cloud-registration / marketplace carry-over 到 collections 侧 | 本地已有 order 侧 peer flow 与 shared bridge substrate；exact-name Flow 当前 `0 hit` | `L2 finance carry-over parity` | `否` | `f9c4...`，次级 `690...` |
| `RevRec_Set_PLG_BD_Pool` | 在 revenue / revrec 侧维护 PLG pool | 本地 `Revenue__c` 字段与 `Order` 侧 revenue rollup 已在；exact-name Flow 当前 `0 hit` | `L2 revrec parity` | `否` | `837...`，次级 `f9c4...` / `salesforce_revrec` |
| `Revenue__c.Name` / `Invoice_Collection__c.Name` / custom line-item `Name` | 维护记录 identity / 编号连续性 | 本地对象与邻近业务 substrate 已在 | `auto-number parity missing` | `通常否` | `837...`、`f9c4...` 邻近 finance 链路 |
| `Order_Activate_Contract_Status` / `_Start` / `_End` / `_Requires_Contract` | 按标准 Salesforce 思路用 `Order.ContractId` 做 activation authority | 本地已明确改成 `Account-level governing-contract policy` | `intentional replacement` | `否` | `salesforce_orders` / `salesforce_order_daily_view` / `dws_salesforce_arr_summary` |
| `Order_Create_Requires_Effective_CSA_MA_Contract` | 历史 Salesforce-era contract gating 名字 | 当前 evidence 更支持已被 governing-contract policy 替代 | `intentional replacement` | `否` | `salesforce_orders` / finance 邻近链 |
| `Auto_Expire_Contract` | 维护 contract 到期状态 | 本地已有 contract number、status stamp、archived autopromote | `L2 contract governance parity` | `否` | `salesforce_orders`、`dws_salesforce_arr_summary`，次级 account governance 面 |
| `Contract_Update_Account_Contract_Valid` | contract 变化后回写 account contract-valid 状态 | 本地 account contract-valid 字段已在；live fixture 还已坐实它会把 `Contract_Number__c`、`Contract_Valid_Date__c`、`Contract_Valid__c` 从 `Effective + PNA` contract 回写到 account | `L2 governance parity` | `否` | 当前更像先打 `salesforce.account` / `nexuscrm_final.nexuscrm_account` / `stg_salesforce_account` 这类 warehouse-modeling 面；`2026-01-14 11:30:26` 还出现过一批只带 `requestor = looker_studio` 的 `salesforce.account` exploratory query，直接扫到 `contract_valid*`，而且同一秒是 `51` 条 `51` 个 distinct query，更像 datasource/schema exploration burst；repo 侧已能坐实 `dbt-dev` staging/test 明确保留这些字段，但命名 `salesforce_accounts.sql` 当前并未投影它们，`warehouse/business_operations/schema/` 目录里也没有 `salesforce_accounts.yml`。`673... / 212...` 仍只是 account-governance 邻近 front-door，不是已坐实的 `contract_valid*` 字段级前台命中 |
| `LeadTrigger` / `LeadAITrigger` | live Apex-only lead runtime 行为 | 本地 parity 补完后仍有 residual trigger 行为 | `runtime boundary` | `是，比较接近` | `fd12...`，以及 `dws_lead_timeline` / `dws_icp_summary` |
| `OpportunityTrigger` / `QuoteTrigger` | live Apex-only opportunity/quote runtime 行为 | 本地 L2 parity 仍需先清 | `runtime boundary` | `是，比较接近` | `1733...`、`837...`、`0f2...` |
| `OrderTrigger` / `RevenueTrigger` / custom line-item trigger surfaces | live finance / revrec / line-item runtime 行为 | 本地 carry-over/helper/rollup parity 仍需先清 | `runtime boundary` | `是，比较接近` | `837...`、`f9c4...`、current/monthly revrec outputs |
| `AccountTrigger` / `Trigger_CampaignMember` | live trigger-only account/campaign-member residue | 本地 account/campaign-member exact-name parity 仍未清完 | `runtime boundary candidate` | `谨慎说` | `583...` / `690...` / `8c6f...` |

## 一句话规则

1. 看见 `exact-name Flow / validation / auto-number` 缺口，默认先读成 `CM 已支持，但 PingCAP L2 还没补齐`。
2. 看见 `字段已在、本地已有同家族 peer、只是语义条件不一样`，默认先读成 `semantic mismatch`。
3. 只有在 `同面 parity 清完以后` 仍必须依赖 live Apex / runtime 的，才升级成 `CM 真未支持`。