Single-cube integration is rarely the real problem in planning programs. The hard problem is synchronized driver exchange across multiple cubes where dimensions are sparse, partially shared, and owned by different business teams.
This article covers a practical architecture for that exact scenario.
Scenario: one model, many planning cubes
Typical enterprise planning landscape:
- Workforce cube for headcount and compensation drivers
- Revenue cube for volume, price, and channel assumptions
- CAPEX cube for project and asset spending
- Consolidated financial cube for P&L, balance sheet, and cash flow
Each cube uses overlapping dimensions, but not identical granularity. That is where integration errors accumulate.
Dimension contract and sparse control
| Dimension | Shared across cubes | Sparse risk | Control strategy |
|---|---|---|---|
| Entity | Yes | Low | Central hierarchy authority |
| Account | Yes | Medium | Cross-cube account mapping table |
| Product | Revenue + Financial | High | Explicit "NotApplicable" member strategy |
| Employee | Workforce only | High | Workforce driver to financial aggregation map |
| Project | CAPEX + Financial | Medium | Project lifecycle state gating |
| Scenario | Yes | Low | Global scenario registry |
Without an explicit sparse-member strategy, data exchange silently drops or misroutes records.
Hub-and-spoke exchange pattern
Use a planning integration hub as the only exchange point. Do not exchange cube-to-cube directly.
Diagram
Rendering diagram...
Why this works:
- One place for mapping rules and validation.
- One reconciliation ledger for all cube interactions.
- One restart path for failed exchanges.
Exchange packet design
Each packet should carry enough metadata to reconstruct context:
json
1{2 "packet_id": "PKT-2026-03-01-REV-0042",3 "source_cube": "Revenue",4 "target_cube": "Financial",5 "scenario": "Plan",6 "period": "FY26.Jan",7 "grain": ["Entity", "Account", "Product", "Channel"],8 "rows": 124889,9 "load_mode": "merge",10 "version": "v3.2.1"11}Store packet metadata separately from payload values. That keeps observability and reprocessing straightforward.
Mapping logic for sparse dimensions
A controlled fallback is required for dimensions that do not exist in target cube.
groovy
1String normalizeMember(String member, boolean supportedInTarget) {2 if (supportedInTarget) return member3 return "NotApplicable"4}5 6def mappedProduct = normalizeMember(row.product, targetSupportsProduct)7def mappedEmployee = normalizeMember(row.employee, targetSupportsEmployee)NotApplicable is not a shortcut. It is a governed mapping outcome that keeps data additive and auditable.
Validation matrix before load
| Check | Severity | Action |
|---|---|---|
| Unknown member in shared dimension | Critical | Fail packet |
| Missing sparse target mapping | Critical | Fail packet |
| Currency mismatch | Critical | Fail packet |
| Parent-level load attempt | Warning | Reject row, continue packet |
| Amount outside tolerance | Warning | Quarantine row, continue packet |
Critical failures stop packet publication. Warnings create quarantined exceptions with clear ownership.
Reconciliation across cube boundaries
Use a standardized reconciliation ledger schema:
sql
1create table planning_recon_ledger (2 packet_id varchar(64),3 source_cube varchar(32),4 target_cube varchar(32),5 period varchar(24),6 scenario varchar(24),7 source_amount decimal(20,4),8 target_amount decimal(20,4),9 variance_amount decimal(20,4),10 status varchar(16),11 created_at timestamp12);Then publish exception dashboards by packet and by dimension intersection.
Restart and replay controls
For multi-cube exchange, replay must be targeted. Full replay creates duplicate downstream impact.
- Replay by
packet_id, not by day. - Enforce immutable packet snapshots.
- Allow partial reprocess only for quarantined rows.
- Re-validate against latest hierarchy version before merge.
If hierarchy changed after original run, force controlled remap review.
Operational ownership model
| Role | Owns |
|---|---|
| FP&A Integration Lead | Packet sequencing and scenario controls |
| Data Engineering | Hub runtime, monitoring, replay framework |
| Controllership | Reconciliation acceptance criteria |
| EPM Admin | Cube metadata readiness and deployment windows |
This ownership split prevents integration tickets from bouncing between teams.
Implementation outcome targets
- Packet success rate above
98.5%during close week - Sparse mapping exception rate below
1% - Cross-cube reconciliation variance below
0.2% - Replay completion time below
15 minutesper packet
Multi-cube planning integration is manageable when dimension governance and replay strategy are designed first, not retrofitted after failures.