Skip to main content

​
The Work Item Foundation

At its core, RISKSHEET does not create a separate data structure. Instead, it provides a specialized interface for viewing and editing Polarion work items that represent risk analysis data. Every row in a Risksheet corresponds to one or more Polarion work items, and every cell value maps to a work item field. This tight coupling with Polarion’s data model means:
  • All data lives in Polarion work items - Changes made in RISKSHEET are immediately reflected in Polarion’s native work item views, and vice versa.
  • Traceability is preserved - Work item links, history, and audit trails remain intact.
  • Permissions apply consistently - Polarion’s role-based access control governs what users can view and edit.
Think of RISKSHEET as a spreadsheet lens over Polarion work items. The spreadsheet is not a copy of the data—it’s a live, editable view that writes directly back to the source work items.

​
The Two-Tier Structure

RISKSHEET displays work items in a two-tier structure: diagram

​
Risk Items (Master Level)

The first tier consists of risk items—work items that represent risks, hazards, failure modes, or other risk-related concepts. These items are configured in the dataTypes.risk section of the configuration and are typically of a custom Polarion work item type (e.g., risk, hazard, failureMode). Risk items are displayed across one or more hierarchical levels defined in the levels configuration. Despite appearing as nested rows (e.g., Failure Mode → Cause), each “level” still represents the same underlying risk work item. The visual grouping is achieved by merging cells based on the controlColumn property. For example:
  • Level 1: Grouped by failureMode field → cells with the same failure mode value are merged
  • Level 2: Grouped by systemItemId (unique work item ID) → each row is a distinct risk item
This creates the illusion of hierarchy, but it’s actually a cell-merging strategy applied to a flat list of risk items. All columns at Level 1 and Level 2 pull data from the same risk work item. See Work Item Visibility and Levels for a deeper explanation of how levels control visual grouping.

​
Task Items (Downstream Level)

The second tier consists of task items—work items that mitigate, control, or address the risks. These are configured in the dataTypes.task section and are linked to risk items via a Polarion link role (e.g., mitigates). Task items appear in columns to the right of risk columns (typically Level 3 or higher). Each task row represents a separate work item linked to its parent risk item. Task columns use the taskLink type and reference task item fields via dot notation (e.g., task.title, task.status). Unlike risk items, task items are not merged—each row is a distinct task work item.
Users often expect to see tasks linked to upstream work items of a risk item (e.g., tasks linked to a parent requirement). RISKSHEET only shows items directly linked to the risk item. To display items connected through multi-level relationships, you must use custom data rendering with server-side queries. See the ticket insight on upstream relationships for details.

​
Work Item Types and Roles

RISKSHEET’s flexibility comes from its ability to work with any Polarion work item type. The configuration defines which types represent risks and tasks:
PropertyPurposeExample
dataTypes.risk.typePolarion work item type for risk rows"risk"
dataTypes.task.typeDownstream work item type(s) — comma-separated for multiple"task,issue"
dataTypes.task.roleLink role connecting tasks to risks — must match a Polarion link role"mitigates"
dataTypes.task.nameDisplay label in the UI"Mitigation Measure"
This design allows RISKSHEET to support diverse workflows:
  • FMEA: Risks = failure modes, Tasks = corrective actions
  • HARA: Risks = hazards, Tasks = safety goals
  • Custom workflows: Any work item type can represent risks or tasks
For guidance on configuring multiple task types, see Configure Multiple Downstream Types.

​
Field Bindings and Column Data

Every column in RISKSHEET maps to a work item field via the bindings property:
Column PurposeBindings ExampleData Source
Risk field"failureMode"Risk item’s failureMode custom field
Task field"task.title"Linked task item’s title field
System field"status"Risk item’s status field
Upstream field"requirement.id"Upstream linked item’s id field
The dot notation (task.title, requirement.id) traverses link relationships:
  1. task refers to the column with "type": "taskLink" and "id": "task"
  2. .title accesses the title field of the linked task work item
This binding system allows columns to display data from:
  • The current risk item (direct field names)
  • Linked task items (via taskLink columns)
  • Linked upstream items (via itemLink or multiItemLink columns)
See Field Mapping for the complete field binding reference.

​
Data Visibility Rules

Not all work items are visible in every Risksheet. Visibility is controlled by:
  1. Document scope: Risk items must be part of the Polarion document that hosts the Risksheet (unless configured otherwise).
  2. Task queries: Task items are loaded based on the document, project, or query properties in the dataTypes.task configuration.
  3. Link relationships: Task items must be linked to a risk item via the configured role.
For example, setting project to a specific project and query to "status:open" limits visible tasks to open items from that project, linked via the configured role. Starting with version 23.7.0, you can load tasks from multiple projects using "projects": "Project1,Project2". Users can then select which project to create new tasks in. See Configure Downstream Traceability Columns for practical examples.
When viewing a Risksheet at a specific revision or baseline, risk items reflect the state of the document at that point in time. Task items, by default, show their latest version unless nextedy.risksheet.downstreamFromRevision=true is set to freeze them at the baseline state.

​
Creating and Linking Work Items

When users create new rows in RISKSHEET:
  1. New risk items are created as Polarion work items of the configured risk type and added to the current document.
  2. New task items are created as work items of the configured task type and automatically linked to the parent risk item via the configured role.
The system handles temporary IDs (prefixed with *) during creation and maps them to permanent Polarion IDs after the transaction commits. This allows users to create multiple related items in a single operation, even when items reference each other. For cross-project configurations, users can select which project to create new task items in, as long as multiple projects are configured in the task.projects property. See Create Your First Risksheet for a practical walkthrough of creating items.

​
Relationship to Architecture

The data model directly reflects RISKSHEET’s Architecture:
  • The client layer renders work items as spreadsheet rows and cells.
  • The server layer mediates between the grid and Polarion, executing queries and transactions.
  • The Polarion data layer stores all work items, fields, and link relationships.
Understanding this three-layer model helps clarify why certain operations (like aggregating data from multiple documents) are not supported: RISKSHEET maintains a 1:1 relationship between documents and grids to preserve data integrity and transaction boundaries.

​
Next Steps

KB ArticlesSupport TicketsSource Code
  • risksheet.json
  • AppConfig.ts
  • PolarionAppConfigManager.java
  • RisksheetDataStorage.java
  • RisksheetProjectProperties.java