This page explains the conceptual foundations behind live data views — why they exist, how they differ from traditional document-based risk tables, and what mental models help you work with them effectively.
Why Live Data Views Exist
Traditional approaches to risk management in Polarion involve either manually maintained tables inside LiveDoc documents or separate tracker-based views that lack the structured, spreadsheet-like layout that safety engineers expect. Neither approach scales well for complex FMEA, HARA, or TARA analyses that involve hundreds of risk items with interconnected failure modes, causes, effects, and mitigation tasks.
Live data views bridge this gap. They give you the familiar grid experience of a desktop spreadsheet application while keeping the data firmly rooted in Polarion’s work item system. Every cell in the grid is bound to a specific field on a specific work item. When you edit a cell, you are editing the work item directly. When a colleague updates a work item through the standard Polarion interface, your grid reflects that change.
Think of a live data view as a transparent window onto your Polarion data, shaped by a configuration that determines which columns appear, how they are formatted, and what relationships they display.
The Relationship Between Views and Data
A common misconception is that the Risksheet grid stores its own copy of data. It does not. The grid is a view layer that reads from and writes to the same Polarion work items that appear in your tracker, LiveDoc modules, and dashboards.
This architecture has several implications:
- No data duplication. There is no separate database or file behind the grid. Changes propagate through the standard Polarion persistence layer.
- Consistent audit trail. Every edit made through Risksheet appears in the Polarion work item history, just as if you had edited the field through the native interface.
- Permission enforcement. The grid respects Polarion’s field-level and work item-level permissions. If a user cannot modify a field in Polarion, they cannot modify it through Risksheet either.
- Revision support. When you open a historical revision of a LiveDoc, the live data view renders the data as it existed at that point in time, and the grid becomes read-only.
How Configuration Shapes the View
Each live data view is defined by a risksheet.json configuration file attached to the LiveDoc document (or inherited from a template). This configuration acts as a lens that determines what you see and how you see it.
The configuration controls:
| Aspect | Configuration Section | Purpose |
|---|
| Which columns appear | columns | Defines each column’s binding, type, header text, width, and editability |
| Which work item types populate the grid | dataTypes | Maps risk items, task items, and upstream items to Polarion work item types and link roles |
| How rows are grouped hierarchically | levels | Defines multi-level structures such as failure mode / cause / effect groupings |
| How cells are formatted dynamically | cellDecorators, styles | Applies conditional CSS classes based on cell values (e.g., color-coding RPN thresholds) |
| What calculated values appear | formulas | Defines JavaScript expressions for derived columns like RPN calculations |
| Which column presets are available | views | Defines saved view configurations that toggle column visibility |
Live data views support template-based configuration inheritance. A global template can define the base column layout for all risk documents in a project, while individual documents can override specific settings. See Configuration Hierarchy for details. Scope of a Live Data View
A live data view is scoped to a specific Polarion LiveDoc document. The work items that appear in the grid are determined by the document’s content — specifically, the work items contained in or referenced by that document.
The dataTypes configuration section further refines this scope by specifying:
- Risk items: The primary work item type that forms the rows of the grid (e.g.,
failureMode, risk, hazard).
- Task items: Downstream mitigation tasks linked to risk items through a specified link role.
- Upstream items: Requirements or design elements linked to risk items, displayed as traceability columns.
Each data type can optionally specify a document property to restrict the scope to items within a particular document, or leave it unspecified to pull items from the entire project.
The exact scoping behavior when combining document-level and project-level queries may vary depending on your Polarion version and Risksheet configuration. Test your specific combination to confirm expected behavior.
Live Rendering and Synchronization
When you open a LiveDoc containing a Risksheet widget, the application loads the configuration and queries Polarion for the relevant work items. The grid renders client-side in the browser, building each row from work item field values and computing formula columns on the fly.
Key characteristics of the rendering model:
- Client-side formulas. Formula columns execute JavaScript functions in the browser. When you change a cell value, dependent formula columns recalculate immediately without a server round-trip.
- Conditional formatting. Cell decorators run after each cell render, applying CSS classes based on the current value. This means that when you change a severity rating, the RPN column recalculates instantly and the color coding updates in real time.
- Server-rendered columns. Some columns use Velocity templates executed on the server side. These columns are always read-only and update only when the page reloads or a save triggers a refresh.
Read-Only Mode and Revisions
Live data views operate in two modes:
- Edit mode — The default when viewing the current revision of a document. Users with appropriate permissions can modify cell values, create new risk items, and manage linked items.
- Read-only mode — Activated automatically when viewing a historical revision, when the
readonly configuration property is set to true, or when the user lacks edit permissions. All cells become non-editable and creation controls are hidden.
When you navigate to a baseline or historical revision of a document, Risksheet automatically switches to read-only mode. This is by design — historical data must remain immutable for compliance and audit purposes.
Live Data Views Compared to Other Polarion Views
Understanding how live data views differ from other ways of viewing work items in Polarion helps clarify their purpose and limitations.
| Feature | Polarion Tracker Table | LiveDoc Table | Risksheet Live Data View |
|---|
| Data source | Work items from query | Static table in document | Work items from document with configured bindings |
| Column layout | Configurable per view | Manual formatting | Defined in risksheet.json |
| Calculated fields | Not supported | Manual calculation | JavaScript formulas with real-time recalculation |
| Conditional formatting | Limited | Manual | Configurable cell decorators with CSS classes |
| Hierarchical rows | Not supported | Manual nesting | Multi-level hierarchy with cell merging |
| Traceability display | Via linked items column | Manual references | Dedicated upstream/downstream columns with inline editing |
| Export | CSV/XML | Document export | Formatted Excel and PDF with column layout preserved |
| Audit trail | Standard Polarion history | Document versioning | Standard Polarion history (same as tracker) |
risksheet.json configuration — determines which fields are visible, how they are arranged, what calculations are performed, and how values are color-coded.
Multiple lenses can exist for the same data. Different documents can reference overlapping sets of work items with different configurations. The data remains consistent because there is only one copy, stored as standard Polarion work items.
This lens model also explains why configuration changes are non-destructive. Changing a column layout, adjusting a formula, or modifying a cell decorator does not alter any work item data. It only changes how that data is presented and interacted with through the grid.
Related Pages
