10Open questions
4High impact
4Medium impact
2Low impact
The org has a custom object Billing__c with 0 records and only system fields (no custom fields, no relationships). It looked promising as a "Billing Schedule" home, but it's clearly a placeholder.
Options:
- A) Abandon it. Use
Asset as the canonical billing-schedule entry (Asset already has billing-frequency, dates, ACV, ARR, etc.).
- B) Build out
Billing__c as a separate object with its own lifecycle.
Recommendation: Option A. Asset is already the de-facto billing schedule. Billing__c should be deleted (or marked deprecated) to avoid confusion.
Affects: BR-004 (Duplicate Sync Prevention), BR-049 (Billing Schedule Auto-Generation), BR-039 (Reconciliation Completeness)
Both OpportunityLineItem and Asset hold the same data (Service dates, ACV, ARR, billing frequency, One_Off). OLI is the deal-time view; Asset is the post-Closed-Won materialised view. We need to know which one drives the Xero invoice creation trigger.
Options:
- A) Asset triggers invoicing. OLI is closed-won snapshot; Asset becomes the live record that the integration watches.
- B) OLI triggers invoicing directly. Asset is just a reporting copy.
- C) Both — OLI for billing schedule generation, Asset for ongoing renewal/term management.
Recommendation: Option C with clear ownership. OLI represents the deal at point of close (immutable per BR-051). Asset is the ongoing live view that the integration triggers from. We need a confirmed flow: OLI → (at Closed Won) → Asset created → Asset triggers Xero sync.
Affects: BR-001, BR-002, BR-004, BR-049, BR-050, BR-051, BR-053, BR-055
OpportunityLineItem.Type__c is currently a string field, length 1300. BR-050 (Derived Opportunity Type) requires 6 controlled values: New Logo, Upsell, Renewal, Downsell, Churn, Reactivation. Without a restricted picklist, automation can write garbage into the field.
Options:
- A) Convert
Type__c to a restricted picklist with the 6 values. Risk: existing data may not match — needs migration plan.
- B) Add a new restricted picklist (e.g.
Movement_Type__c) and deprecate the existing Type__c.
- C) Keep as string, enforce values via Apex/validation rule. Simpler but no UI control.
Recommendation: Option B is safest. Create Movement_Type__c as a restricted picklist, leave existing Type__c in place to avoid breaking anything. Migrate values over time.
Affects: BR-050 (Derived Opportunity Type), BR-051 (Classification Immutability), BR-053 (Previous Asset Linkage), BR-055 (Reactivation), BR-056 (Delayed Renewal)
The same field name lives on three objects. There's no documented sync logic between them. Different rules might read from different objects, causing inconsistency.
Options:
- A) Contract is source of truth. OLI/Asset auto-populate from Contract. Edits flow Contract → others.
- B) Asset is source of truth (closest to billing event). Contract reflects what was signed; OLI is point-in-time.
- C) Each is independent (current state). Document which rule reads from which.
Recommendation: Option A. Contract is signed-and-locked, the legal source of truth. OLI/Asset should be cascaded copies. Add a one-time backfill + ongoing trigger.
Affects: BR-007, BR-008, BR-009, BR-010, BR-011, BR-013, BR-045, BR-046
Per BR-008/009, Service_Commencement_Date__c and Service_End_Date__c are "currently being misused for testing dates". A new Contracted_Asset_Start/End_Date__c was proposed to disambiguate.
Options:
- A) Create new fields
Contracted_Asset_Start_Date__c / End_Date__c; migrate clean data; deprecate misuse.
- B) Reclaim the existing fields — clean up data, define them properly going forward, keep
Testing_Start_Date__c / End_Date__c as separate fields.
Recommendation: Option B. Cleaner schema. Existing names already match the rules; the issue is data quality, not field naming. Audit the data, fix bad records, add validation rule to prevent future misuse.
Affects: BR-008, BR-009, BR-010
BR-040 requires a controlled Region field on Account aligned to geographic reporting (EMEA, Americas, APAC). The current field is a free-text string, so reporting can't aggregate cleanly.
Options:
- A) Add a new
Region__c picklist field; backfill from current string; deprecate the old field.
- B) Convert the existing string to a restricted picklist. Risk: existing values won't match.
Recommendation: Option A. Add Region__c picklist (EMEA, Americas, APAC, plus any sub-regions). One-time backfill script. Old field stays as historical free text.
Affects: BR-040 (Region Field Requirement)
BR-050 wants 6 movement types. Current Opportunity.Type picklist has 5 values (Renewal, Up-sell, New Business, Renewal w/ Up-sell, Whitespace). Per BR-050 the classification lives on the line, not the deal — so deal-level Type may become a derived rollup.
Options:
- A) Add the new 6 values to
Opportunity.Type alongside existing values, keep both line-level and deal-level Types.
- B) Use OLI
Movement_Type__c only (per Q3). Opportunity.Type becomes a derived rollup (e.g., "Mixed" if lines disagree).
- C) Replace existing 5 values with the new 6. Highest risk — breaks reports/automation referencing old values.
Recommendation: Option B. Line-level is correct per BR-050. Opp-level Type becomes a formula that rolls up line types.
Affects: BR-050, BR-051, plus any existing Opp.Type-based reports/automation
Asset.Billing_Schedule__c picklist has real values (Annual, Semi-Annual, Tri-Annual, Quarterly, Monthly, Type 3 (Partners), One-Off). Asset.Type_of_Billing_Schedule__c picklist exists but has only "test" as a value. Same situation on Contract and OLI.
Options:
- A)
Billing_Schedule__c is canonical. Delete Type_of_Billing_Schedule__c on each object.
- B) Keep both — they may serve different purposes (frequency vs invoicing pattern).
Recommendation: Option A. The "test" value strongly suggests it was a draft never finished. Confirm with team and remove.
Affects: BR-002 (Mandatory fields), BR-049 (Billing Schedule generation)
Contract.Business_Line__c has 8 values (C9, Kaizen, Kaizen BV, LRH, Red Deer, SDS, SRB, CloudSinc). BR-030 requires routing each invoice to the correct Xero org. Decision DEC-004 in the requirements is still TBC: how many Xero tenants exist?
Options:
- A) Single Xero tenant — route all invoices there, use Business Line as a label only.
- B) One tenant per business line — 8 tenants, custom metadata mapping table drives routing.
- C) Hybrid — main Kaizen tenant + 1-2 subsidiaries with their own tenants.
Recommendation: Need confirmation from CFO. Build the routing infrastructure (CMT lookup table) regardless — it's cheap and future-proof.
Affects: BR-029 (Billing Entity Dropdown), BR-030 (Xero Org Routing), BR-031 (Intercompany Treatment), BR-047 (Intercompany Revenue Elimination)
After mapping rules to existing fields, ~15 fields are genuinely new. Examples: Opportunity.TCV__c, Opportunity.SOW_Currency__c, Asset.Year_N_Total__c, Asset.Recurring_ACV__c, several flag fields on Xero_Invoice__c.
Options:
- A) Async — share the field list, Ethan creates them, we deploy when ready.
- B) Paired session — walk through each, agree types/required/picklist values, deploy together.
- C) We deploy via SFDX from this project. Ethan reviews the metadata XML.
Recommendation: Option C. Field metadata in this repo as the source of truth, deployable via sf project deploy. Ethan reviews PRs. Avoids drift.
Affects: All Tier 2 rules (most of the rule set)
Quick decision summary (for the meeting)
| Q |
Topic |
Recommendation |
| Q1 | Billing__c object | Abandon — use Asset |
| Q2 | Asset vs OLI | OLI for deal close, Asset for ongoing live record |
| Q3 | OLI Type__c | New Movement_Type__c picklist; deprecate Type__c |
| Q4 | Date source of truth | Contract → cascades to OLI/Asset |
| Q5 | Testing-date misuse | Reclaim existing fields, separate Testing_*_Date__c fields |
| Q6 | Region field | New Region__c picklist |
| Q7 | Opportunity.Type extension | Use OLI Movement_Type only; Opp.Type becomes derived rollup |
| Q8 | Type_of_Billing_Schedule | Delete; Billing_Schedule__c is canonical |
| Q9 | Multi-entity Xero | Need CFO answer; build routing CMT regardless |
| Q10 | New field deployment | SFDX-managed; Ethan reviews PRs |