Dear IBM Planning Analytics Product Team,

Summary

In current versions of IBM Planning Analytics Workspace (PAW) (up to 2.1.18 / 3.1.5 as of March 2026), formatting in Cube Views / Explorations is limited to the entire cell value. Supported formatting includes background color, font style, alignment, borders, conditional rules, and limited icon sets.

We request support for rich text / partial formatting within a single cell, allowing different styles (color, bold, italic, underline, etc.) to be applied to specific segments of the cell content.

This capability would significantly improve financial and operational reporting usability and close an important gap between PAW dashboards and traditional spreadsheet-based reporting workflows.

Key Business Use Cases

Finance and controlling teams frequently need to combine numeric values with contextual indicators within a single visual element.

Variance reporting

1,234,567 (+8.7%)

Desired formatting:

• 1,234,567 → standard numeric formatting

• (+8.7%) → green / bold (or red if negative)

Budget monitoring

Budget: 750k (overdue)

Desired formatting:

• Budget: 750k → neutral

• (overdue) → red / italic

KPI with commentary

Margin: 18.4% ▲ Strong

Desired formatting:

• value

• icon / indicator

• qualitative assessment in separate style

Forecast commentary

Forecast Q2: 2.1M Risk: Supply chain delay

Desired formatting:

• numeric forecast

• warning text highlighted in orange

These presentation patterns appear daily in:

• P&L / Income Statements

• Management and Executive Dashboards

• Variance Analysis Reports

• Operational Scorecards

• Rolling Forecast Reviews

Without partial cell formatting, these layouts require significant workarounds.

Current Limitations and Workarounds

In PAW Cube Views and Explorations today:

• Formatting rules apply only to the entire cell

• Conditional formatting cannot target parts of a string

• Icon sets are limited and cannot be mixed with text content

• Concatenated rule outputs lose all styling control

Typical workarounds include:

1. Splitting measures

Value | Δ | Δ %

Result:

• wider views

• reduced readability

• additional cube elements

2. Additional widgets

Using separate KPI widgets and text widgets to simulate formatting.

Result:

• fragmented layouts

• more complex dashboards

3. Switching to spreadsheet reporting

Using **Planning Analytics for Excel or Microsoft Excel to finalize reports.

Result:

• duplicated logic

• Excel shadow IT

• reduced governance

Impact on Adoption and ROI

Many finance teams still rely on Excel to produce the final presentation layer for variance reports and financial statements.

The main reasons include:

• flexible cell formatting

• partial formatting inside cells

• easy combination of values and annotations.

Adding partial cell formatting to PAW would:

• reduce reliance on Excel-based reporting

• increase adoption of web-based PAW dashboards

• improve readability of enterprise financial reports

• simplify cube model design by reducing auxiliary measures

• accelerate report development cycles.

For many organizations, this capability would significantly strengthen PAW as a primary reporting interface, not only a planning interface.

Technical Context

From a TM1 engine perspective, cube cells currently return either:

• numeric values

• string values

Formatting is applied primarily at the client rendering level within PAW.

Because of this architecture, partial cell formatting could potentially be implemented as a lightweight rendering-layer enhancement, without requiring changes to the underlying cube storage model.

For example:

• TM1 rules could return formatted strings

• PAW could interpret lightweight markup or delimiters

• the rendering engine would apply styles only in the client view.

This approach would preserve existing cube performance characteristics.

Possible Implementation Approaches

Option 1 – Markdown-style syntax

Example rule output:

1234567 **(+8.7%)**

Rendered result:

1234567 (+8.7%)

Markdown is already supported in several PAW widgets, which suggests that extending the renderer could be feasible.

Option 2 – Lightweight inline style tags

Example:

1234567 {green,bold:(+8.7%)}

The renderer interprets inline styling instructions.

Option 3 – Pattern-based formatting in Format Manager

Allow Format Manager to apply formatting to substrings using:

• delimiters

• regex-like patterns

• rule-generated markers.

Performance and Scalability Considerations

To ensure scalability in large cube views:

• formatting interpretation could occur only for visible cells

• rendering results could be cached within the existing PAW cellset rendering pipeline

• string length limits could be applied (e.g., 500 characters per cell)

• HTML or complex markup could be excluded from the initial implementation.

This would minimize any performance impact on the TM1 server.

Suggested Phased Rollout

Phase 1 (Minimum Viable Feature)

• partial formatting for string cells

• Markdown-style support (bold, italic, color)

• rule-generated string outputs supported

This phase would already unlock the majority of financial reporting use cases.

Phase 2 (Enhanced Formatting)

• support for numeric cells with formatted prefixes/suffixes

• additional style options (underline, font size)

• conditional partial formatting (e.g., negative variance automatically red).

Competitive Context

Modern analytics and dashboarding platforms increasingly support rich or conditional text formatting within cells, allowing users to combine values and contextual information in compact visual elements.

Introducing this capability in PAW would improve competitiveness for enterprise financial reporting and align the platform more closely with user expectations shaped by spreadsheet environments.

Conclusion

Partial cell formatting would represent a significant usability improvement for finance, controlling, and operational reporting teams.

It would:

• improve report clarity

• simplify model design

• reduce Excel dependencies

• strengthen PAW as a complete enterprise reporting platform.

We strongly support this enhancement and encourage the community to share additional use cases and vote for this feature.

Thank you for considering this request.

Best regards
Vitalij