# Salesforce / CM / BI Issue Backlog

Date: `2026-07-07`

## 用法

这份文档不是新的研究结论。

它只是把
`docs/salesforce-cm-bi-final-conclusion-2026-07-07.md`
里已经成熟的
`front-door report surface`
草稿，
整理成更适合直接开 GitHub issue 的短格式。

默认规则：

- 先开
  `L2 parity`
  issue
- 只有同面 parity 清完后仍有稳定残差，
  才升级成
  `runtime`
  题

## 去重规则

这 8 包是按
`front-door report surface`
切的，
不是按
`实现机制`
切的。

所以开票时要额外遵守一条去重规则：

- 一个共享实现点，
  可以在多个报表包里出现
- 但真正落到 GitHub issue 时，
  最好只选一个
  `主票`
  来承载实现
- 其它报表包只保留
  `依赖此主票`
  或
  `验收时一并回归`
  的关系

## 共享机制依赖图

下面这张表是为了避免重复开票。

| 共享机制 | 首选主票 | 次级受影响 front-door | 为什么要去重 |
|---|---|---|---|
| `Lead_StatusChangeTimestamp` 语义收窄 | `fd12...` | 次级会外溢到 `salesforce_leads -> dim_lead / dws_lead_timeline / dws_icp_summary` | 这是典型的单机制语义收窄，没必要拆成多张 Lead 票 |
| `Campaign_Member_Key_Message_Update` | `8c6f...` | `fd12...` | attribution 是最直接 consumer，lead funnel 只做次级回归面 |
| `Account_Current_Order_Type` | `583...` | `690...`，以及 `837...` / `f9c4...` 邻近链路 | 这是最典型的 shared-key 维度机制；当前 direct front-door 命中最硬的还是 current-month finance / tenant-bridge 复合面，不要在 `673... / 212...` 重复承载实现 |
| `Account_Partner_Sales_Owner_Set` | `673... / 212...` | `583...` | 它更像 account forecast / governance 面的 owner 维度机制；`583...` 更适合做次级回归面 |
| `Account_Contract_Valid_Message` | `673... / 212...` | `690...` 只保留 governance 邻近观察，不单独承载实现 | 这条更偏 governance/account forecast，不该混进 `583...` 当前月 finance 主票；当前 front-door 还没把 `contract_valid*` 打成强直命中 |
| `Order_Org_Auto_Set_Account_Create / Update` | `583...` | `837...`、`f9c4...`、`690...` | 这是最关键的 account/org/order carry-over 共享缺口，跨 4 个 front-door；必须有一个主票 |
| `Order_Set_PLG_BD_Pool` | `837...` | `583...`、`f9c4...` | 这条最直接打 finance segmentation / ARR summary，其他面应作为回归消费面 |
| `RevRec_Set_PLG_BD_Pool` | `837...` | `f9c4...` | revrec helper 的最直接 front door 是 ARR / forecast；`f9c4...` 更像次级 tenant/account 验收面 |
| `Collection_Set_PLG_BD_Pool` | `f9c4...` | `salesforce_order_daily_view` / `monthly_revrec_collections` 邻近 finance 面 | 这条是 collections 语义本身，主票应放在 collections 最直接 consumer 面 |
| `Collection_Amount_and_Payable_Amount_exc_tax` / `_Update` | `f9c4...` | `salesforce_order_daily_view` / `salesforce_org_monthly_revrec` | helper-field parity 也是 collections 主线，不应拆成多张 payable / revrec 小票 |
| `Cloud_Registration_Source_from_Org_to_Collections` | `f9c4...` | `690...` | 主体是 collections + marketplace bridge；`690...` 主要做 tenant bridge 回归 |

## 建议开票方式

如果下一步真的开始建 issue，
最稳的方式不是
`一口气开 8 张互相重叠的票`
，
而是分两层：

1. `front-door 主票`
   用这份文档里的 8 包确定 blast radius 和验收面。
2. `共享机制主票`
   对重复出现的核心机制，只选一个 front-door 作为实现主票。

一个够用的默认映射是：

- `fd12...`
  持有
  `Lead_StatusChangeTimestamp`
- `8c6f...`
  持有
  `Campaign_Member_Key_Message_Update`
- `583...`
  持有
  `Account_Current_Order_Type`
  和
  `Order_Org_Auto_Set_Account_*`
- `673... / 212...`
  持有
  `Account_Partner_Sales_Owner_Set`
  和
  `Account_Contract_Valid_Message`
- `837...`
  持有
  `Order_Set_PLG_BD_Pool`
  和
  `RevRec_Set_PLG_BD_Pool`
- `f9c4...`
  持有
  `Collection_*`
  和
  `Cloud_Registration_Source_from_Org_to_Collections`

这样做的好处是：

- 不会在 `583... / 690...`
  两张 current-order-type / tenant-bridge 面里重复写
  `Account_Current_Order_Type`
- 不会在 `583... / 673... / 212...`
  三张 account 面里重复写
  `Account_Partner_Sales_Owner_Set`
- 不会在 `583... / 837... / f9c4...`
  三张 finance 面里重复写三次
  `Order_Org_Auto_Set_Account_*`
- 不会把
  `Campaign_Member_Key_Message_Update`
  既当 attribution 票，
  又当 lead funnel 主票

## 已开票波次

截至 `2026-07-07`，当前已经开出的 front-door 主票是：

- `#3701`
  `1733...`
  Opportunity/Quote cleanup parity
- `#3703`
  `8c6f...`
  CampaignMember response/involvement parity
- `#3702`
  `fd12...`
  Lead lifecycle timestamp narrowing
- `#3708`
  `583...`
  Account/Order shared-key parity
- `#3706`
  `837...`
  Order/Revenue finance carry-over parity
- `#3705`
  `f9c4...`
  Order/Invoice Collection/Revenue bridge parity
- `#3707`
  `673... / 212...`
  Account dimension governance parity

`690...`
当前先不单独开主票。
默认读法：
把它当
`583...`
和
`#3707`
这组 current-order-type / owner-governance 主票的次级消费面；
只有在前两组 parity 清完后，
它仍独立表现出 tenant/account bridge 漂移，
再补独立 front-door issue。

## 1. `1733...` Pipeline Data Quality / Cleanup

**Title**

`[L2 Parity] Restore Opportunity/Quote cleanup semantics for report 1733 pipeline data quality surface`

**Problem**

`1733...` 这张前台 data-quality / cleanup 面，直接消费 `Opportunity` 的 stage / forecast / owner-team / close/launch 语义，以及 `Quote` 的 service-window / nonstandard-term 邻近语义。当前本地 substrate 已在，但 `Quote_update_nonstandard_conditions_checkbox`、`Quote_update_nonstandard_conditions_checkbox_2`、`OpportunityShareToPersalesOwner`、`OpportunityUpdateShareToPerSalOwner` 仍是 `0 hits`。当前更像 `L2 Opportunity/Quote exact-flow parity` 缺口，不是 `CM runtime` 缺口。

**Scope**

- 补齐 `Quote_update_nonstandard_conditions_checkbox`
- 补齐 `Quote_update_nonstandard_conditions_checkbox_2`
- 补齐 `OpportunityShareToPersalesOwner`
- 补齐 `OpportunityUpdateShareToPerSalOwner`
- 对齐 Quote/Opportunity 邻近 validation activation-state

**Acceptance**

- `owner_team`
- `stage_name`
- `forecast_category`
- `probability`
- `close_date`
- `launch_date`
- `quote_service_start_date`
- `quote_service_end_date`
- nonstandard-term / quote cleanup 邻近字段

**Look First**

- `packs/Salesforce-PingCAP-L2/flows/Std_OpportunityStageDerivedFields.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Opportunity_Cloud_Order_Type_Set.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Opportunity_Close_Date_Auto_Set.flow.json`
- `packs/Salesforce-PingCAP-L2/objects/Quote.json`
- `packs/Salesforce-PingCAP-L2/validation/standard_validation_rules.json`

**Upgrade To Runtime When**

同面 exact-flow parity 和 activation-state mismatch 清完后，`1733...` 仍稳定出现 `owner_team` 或 quote cleanup 语义漂移。

## 2. `8c6f...` Campaign Attribution / Contact-Opportunity Touch

**Title**

`[L2 Parity] Restore CampaignMember response/involvement semantics for report 8c6f attribution surface`

**Problem**

`8c6f...` 这张 attribution 前台面，直接吃 `CampaignMember.first_responded_date`、response / involvement、`contact_response_date`、`attributed_arr` 这条链。本地 first/last-touch substrate 已在，`convertLead` 也已支持 attribution preview / child relink；当前最确定的缺口仍是 `Campaign_Member_Key_Message_Update` 在本地 pack 与 final merged pack 中 `0 hits`。当前最适合先开成 `L2 CampaignMember exact-flow parity` issue。

**Scope**

- 补齐 `Campaign_Member_Key_Message_Update`
- 用同一前台面验证 response / involvement 语义恢复
- Contact stitching / residual trigger 只记为升级条件，不并入本票

**Acceptance**

- `first_responded_date`
- `campaign_member_status`
- `has_responded`
- `is_contact_involved`
- `contact_involvement_level`
- `contact_response_date`
- `attributed_arr`
- `attributed_acv`

**Look First**

- `packs/Salesforce-PingCAP-L2/flows/Lead_Set_First_And_Last_CampaignMember.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Contact_Set_First_And_Last_CampaignMember.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Std_ConvertLeadCampaignPreview.flow.json`
- `packs/Salesforce-PingCAP-L2/actions/invocable_standard_actions.json`
- `packs/Salesforce-PingCAP-L2/objects/CampaignMember.json`

**Upgrade To Runtime When**

`Campaign_Member_Key_Message_Update` parity 补齐后，`8c6f...` 仍稳定出现 response / involvement / attribution 漂移。

## 3. `583...` Account + Current/Monthly Order MRRARR Composite

**Title**

`[L2 Parity] Restore Account/Order shared-key semantics for report 583 current-month MRRARR surface`

**Problem**

`583...` 这张前台复合面，直接吃 `Account` shared-key、`Org` bridge、`Order` current-month finance，以及 `order_product_family` 这条链。本地桥件并不是空白，但 `Account_Current_Order_Type`、`Order_Org_Auto_Set_Account_Create/_Update`、`Order_Set_PLG_BD_Pool` 仍是 `0 hits`。`Account_Partner_Sales_Owner_Set` 对这张面当前更适合作为 `#3707` 的次级回归项，而不是这张 current-month finance 主票的实现主范围。当前更像 `L2 Account/Order exact-flow parity` 缺口。

**Scope**

- 补齐 `Account_Current_Order_Type`
- 补齐 `Order_Org_Auto_Set_Account_Create`
- 补齐 `Order_Org_Auto_Set_Account_Update`
- 补齐 `Order_Set_PLG_BD_Pool`

**Acceptance**

- `account_number`
- `fy26_icp`
- `fy26_segmentation`
- `account_current_order_type`
- `account_id`
- `tenant_id`
- `order_product_family`
- `arr_usd_cd_rate_current_month`
- `mrr_usd_cd_rate_finance`

**Look First**

- `packs/Salesforce-PingCAP-L2/objects/Account.json`
- `packs/Salesforce-PingCAP-L2/flows/Org_Set_Account.flow.json`
- `packs/Salesforce-PingCAP-L2/objects/Order.json`
- `packs/Salesforce-PingCAP-L2/flows/Cloud_Registration_Source_from_Org_to_Order.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Order_Default_RevRec_Entity.flow.json`

**Upgrade To Runtime When**

account/order exact-flow parity 清完后，`583...` 仍稳定出现 `account_current_order_type`、`order_product_family`、current-month MRRARR 漂移。

## 4. `837...` ARR Summary + Regional/Company Forecast

**Title**

`[L2 Parity] Restore Order/Revenue finance carry-over semantics for report 837 ARR summary surface`

**Problem**

`837...` 这张 ARR / forecast 复合面，把 `Opportunity` 的 ARR/forecast、`Order` 的 current-month finance、`Revenue__c` 的 revrec helper，以及 line-item product-family 混在同一个 front-door surface。当前本地已有 `Order_Default_RevRec_Entity`、`Order` 对 `Revenue__c` 的 rollup、custom line-item 公式/rollup；但 `Order_Org_Auto_Set_Account_Create/_Update`、`Order_Set_PLG_BD_Pool`、`RevRec_Set_PLG_BD_Pool` 仍是 `0 hits`。当前更像 `L2 finance carry-over + revrec parity` 缺口。

**Scope**

- 补齐 `Order_Org_Auto_Set_Account_Create`
- 补齐 `Order_Org_Auto_Set_Account_Update`
- 补齐 `Order_Set_PLG_BD_Pool`
- 补齐 `RevRec_Set_PLG_BD_Pool`

**Acceptance**

- `arr_amount_usd`
- `accurate_acv_amount`
- `order_product_family`
- `arr_usd_cd_rate_current_month`
- `mrr_usd_cd_rate_finance`
- `Recognized_Revenue_Amount__c`
- `Amount_Before_Adjust__c`

**Look First**

- `packs/Salesforce-PingCAP-L2/objects/Order.json`
- `packs/Salesforce-PingCAP-L2/objects/Revenue__c.json`
- `packs/Salesforce-PingCAP-L2/objects/Order_Product__c.json`
- `packs/Salesforce-PingCAP-L2/flows/Order_Default_RevRec_Entity.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Cloud_Registration_Source_from_Org_to_Order.flow.json`

**Upgrade To Runtime When**

order/revenue exact-flow parity 清完后，`837...` 仍稳定出现 `Recognized_Revenue_Amount__c`、`Amount_Before_Adjust__c`、`order_product_family` 漂移。

## 5. `f9c4...` Activated-Order / Monthly Revrec by Account+Tenant

**Title**

`[L2 Parity] Restore Order/Invoice Collection/Revenue bridge semantics for report f9c4 activated-order revrec surface`

**Problem**

`f9c4...` 这张 front-door finance 面，直接把 activated-order、monthly revrec、tenant/account bridge、`order_product_family` 和 collections helper 拼在一起。当前本地 `Invoice_Collection__c` helper 字段和 `Order` 侧 rollup 已经不少，但 live 高价值 exact-name 缺口仍很清楚：`Collection_Set_PLG_BD_Pool`、`Collection_Amount_and_Payable_Amount_exc_tax/_Update`、`Cloud_Registration_Source_from_Org_to_Collections`，以及同组 `Order_Org_Auto_Set_Account_*` / `Order_Set_PLG_BD_Pool` / `RevRec_Set_PLG_BD_Pool`。当前更像 `L2 Order/IC/Revenue carry-over parity` 缺口。

**Scope**

- 补齐 `Order_Org_Auto_Set_Account_Create`
- 补齐 `Order_Org_Auto_Set_Account_Update`
- 补齐 `Order_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`
- 补齐 `RevRec_Set_PLG_BD_Pool`

**Acceptance**

- `tenant_id`
- `tenant_name`
- `account_current_order_type`
- `order_product_family`
- `mrr_usd_cd_rate_finance`
- `collections_status_c`
- `invoice_status_c`
- `cash_collected_c`
- `collections_amount_exc_tax_c`
- `payable_amount_usd_2_exc_tax_c`
- `plg_bd_pool_c`
- `marketplace_c`

**Look First**

- `packs/Salesforce-PingCAP-L2/objects/Invoice_Collection__c.json`
- `packs/Salesforce-PingCAP-L2/objects/Order.json`
- `packs/Salesforce-PingCAP-L2/objects/Revenue__c.json`
- `packs/Salesforce-PingCAP-L2/flows/Cloud_Registration_Source_from_Org_to_Order.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Order_Default_RevRec_Entity.flow.json`

**Upgrade To Runtime When**

order / collection / revrec exact-flow parity 清完后，`f9c4...` 仍稳定出现 collections helper、marketplace bridge、monthly revrec 漂移。

## 6. `fd12...` Lead Funnel / ICP Path

**Title**

`[L2 Parity] Narrow Lead lifecycle timestamp semantics for report fd12 lead funnel surface`

**Problem**

`fd12...` 这张前台 lead funnel / ICP 面，直接吃 `Lead` lifecycle、`lead_mql_timestamp`、`lead_iqm_timestamp`、campaign path、lead-account stitching。当前本地 `Lead` substrate 已在：`IQM_Completion_Flow`、`Lead_Status_Duration`、`Std_ConvertLeadCampaignPreview` 都已落地。但 `Lead_StatusChangeTimestamp` 目前仍只是近似承接，因为本地 `Lead_Status_Duration` 只要 `Status IsChanged` 就写时间戳，而 live 语义更窄；同时 Lead 长尾 assignment / reminder / notification parity 仍未完全追回。当前更像 `L2 Lead lifecycle parity` 缺口。

**Scope**

- 收窄 `Lead_StatusChangeTimestamp` 的本地语义
- 记录 Lead 长尾 assignment / reminder / notification parity 仍需继续追回
- 不把 `Campaign_Member_Key_Message_Update` 并入本票

**Acceptance**

- `lead_status`
- `lead_mql_timestamp`
- `lead_iqm_timestamp`
- `lead_surrogate_key`
- `first_touch_campaign`
- `last_touch_before_iqm`
- `last_touch_before_opp_creation`

**Look First**

- `packs/Salesforce-PingCAP-L2/flows/Lead_Status_Duration.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/IQM_Completion_Flow.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Std_ConvertLeadCampaignPreview.flow.json`
- `packs/Salesforce-PingCAP-L2/actions/invocable_standard_actions.json`
- `packs/Salesforce-PingCAP-L2/objects/Lead.json`

**Upgrade To Runtime When**

`Lead_StatusChangeTimestamp` 语义收窄且同面 Lead lifecycle 邻近 parity 清理后，`fd12...` 仍稳定出现 lifecycle timestamp / lead path 漂移。

## 7. `690...` PLG Signup / Billing-Capable Cloud Funnel（默认不单开）

**Title**

`[L2 Follow-up] Audit residual tenant-bridge drift for report 690 PLG signup surface`

**Problem**

`690...` 这张 PLG / billing-capable cloud funnel 面，当前最硬的 report-backed 证据命中的是 `tenant_*` 字段和 `model_plg` funnel metric，还没有把 `Lead` front door、`account_id`、`account_current_order_type` 或 `contract_valid*` 打成 direct field hit。它更像 `583...` 和 `673... / 212...` 这两组主票清理后的次级 consumer：如果 current-order-type、owner / governance、order-side carry-over 清完以后，这张表还漂，再把它单独升级成 follow-up issue。

**Scope**

- 明确依赖 `583...` 的 `Account_Current_Order_Type`
- 明确依赖 `#3707` 的 `Account_Partner_Sales_Owner_Set` / `Account_Contract_Valid_Message`
- 把 `Order_Org_Auto_Set_Account_*` 对 tenant bridge 的回流污染明确写成依赖/邻近项
- 只在依赖清完后仍残留 drift 时，再补独立实现票

**Acceptance**

- `tenant_id`
- `tenant_name`
- `tenant_email`
- `tenant_region`
- `new_users_count`
- `traffic_funnel_type`
- tenant/account bridge 邻近 residual drift

**Look First**

- `packs/Salesforce-PingCAP-L2/objects/Account.json`
- `packs/Salesforce-PingCAP-L2/autonumber/counters.json`
- `packs/Salesforce-PingCAP-L2/autonumber/formats.json`
- `packs/Salesforce-PingCAP-L2/flows/Org_Set_Account.flow.json`
- `packs/Salesforce-PingCAP-L2/flows/Cloud_Registration_Source_from_Org_to_Order.flow.json`

**Upgrade To Runtime When**

`583...` 与 `#3707` 清理后，`690...` 仍稳定出现 tenant/account bridge 漂移。

## 8. `673... / 212...` Account + Forecast Surfaces

**Title**

`[L2 Parity] Restore Account dimension governance semantics for 673/212 forecast surfaces`

**Problem**

`673...` 和 `212...` 这两张 front-door account / forecast 面，当前直接点 `account_number`、`fy26_icp`、`fy26_segmentation`、`account_id`、`account_name`、`account_industry`、owner / sales-team 邻近字段、`tenant_id`、`tenant_region` 这组 shared-dimension / forecast 字段。本地 account/org substrate 已在：`Account_ID__c` auto-number、`Org_Set_Account`、`salesforce_accounts` / `dim_org` / `dim_tenant` 这组链路都已有明确证据。但当前更像 `Account_Partner_Sales_Owner_Set` 这类 owner-governance parity 缺口，再带一层 `Account_Contract_Valid_Message` 邻近治理差异。相反，`Account_Current_Order_Type` 当前更适合留在 `583...` 主票，不再放进这组 forecast surface 的实现主范围。

**Scope**

- 补齐 `Account_Partner_Sales_Owner_Set`
- 补齐 `Account_Contract_Valid_Message` / `_1` 邻近 parity
- tenant bridge 邻近漂移保留为第二层 cleanup

**Acceptance**

- `account_number`
- `fy26_icp`
- `fy26_segmentation`
- `account_id`
- `account_name`
- `account_industry`
- `owner_user_id`
- `sales_team_name`
- `tenant_id`
- `tenant_region`
- account contract-valid / governance 邻近字段

**Look First**

- `packs/Salesforce-PingCAP-L2/objects/Account.json`
- `packs/Salesforce-PingCAP-L2/autonumber/counters.json`
- `packs/Salesforce-PingCAP-L2/autonumber/formats.json`
- `packs/Salesforce-PingCAP-L2/flows/Org_Set_Account.flow.json`
- `packs/Salesforce-PingCAP-L2/objects/Contract.json`

**Upgrade To Runtime When**

account-side exact-flow parity 清理后，`673... / 212...` 仍稳定出现 account dimension / forecast snapshot / governance 漂移。

## 执行顺序

默认顺序：

1. `1733...`
2. `8c6f...`
3. `fd12...`
4. `583...`
5. `837...`
6. `f9c4...`
7. `673... / 212...`
8. `690...`
   仅在 `583...` 与 `#3707` 清理后仍有残差时再单开

理由：

- 前三包 scope 更窄，证据更干净
- 中间三包 finance blast radius 更大，但依赖更多
- 最后两包更偏 shared-dimension / governance，需要前面 account/order 邻近 parity 的结果辅助判断