Skip to main content

​
Work Items as Grid Rows

Each row in the Risksheet grid represents a Polarion work item from the document. The work item type is determined by the dataTypes configuration. A typical FMEA setup defines two primary data types:
Data TypePurposeExample Work Item Type
dataTypes.riskMain risk items (failure modes, hazards)Risk, FMEARisk, HARAHazard
dataTypes.taskDownstream mitigation tasksTask, MitigationAction
The dataTypes.risk.type property specifies which Polarion work item type appears as the main row items. The dataTypes.task.type property defines the type for linked downstream tasks. Both properties support dynamic evaluation, allowing the type to be resolved at runtime from Polarion expressions.
Despite the name, Risksheet can be configured for non-risk use cases. For example, you can set up a requirements traceability matrix with Requirements as main items and Test Cases as downstream, by configuring the appropriate work item types in the dataTypes section. The grid itself is type-agnostic — only the configuration determines what appears.
diagram This architecture means that Risksheet is not a separate data silo. All risk data remains in Polarion’s native storage, indexed by Polarion’s search engine, and governed by Polarion’s access control and versioning system.

​
Columns Map to Fields

Each column in the grid binds to a Polarion work item field through the binding property (or equivalently, the id property). When you edit a cell and save, the value is written to the corresponding field on the work item. 
{
  "header": "Severity",
  "binding": "sev",
  "type": "int",
  "width": 80
}
Column types are auto-detected from Polarion field definitions when not explicitly specified. The system recognizes a wide range of types:
Column TypeData BindingBehavior
Text (default)String fieldsFree-text editing with optional autocomplete
int, float, currencyNumeric fieldsNumeric input with formatting
enum:<enumId>Enum fieldsSingle-select dropdown
multiEnum:<enumId>Multi-enum fieldsMulti-select picker with chip/tag display
rating:<ratingId>Rating fieldsDropdown with risk-specific rating scales
booleanBoolean fieldsCheckbox display
date, datetime, timeDate fieldsDate picker with locale formatting
workflowStatus fieldWorkflow-aware dropdown with valid transitions
itemLinkLink relationshipsSingle linked item with autocomplete
multiItemLinkLink relationshipsMultiple linked items
taskLinkTask relationshipsLinked task with autocomplete
System fields like id, status, type, project, and outlineNumber are always set to read-only. Formula columns (formula property) and server-rendered columns (serverRender property) are also read-only by default. Additionally, fields such as author, resolution, created, and updated are automatically protected from modification.

​
Hierarchical Levels

Risksheet supports multi-level row hierarchies through the levels array. Levels enable cell merging, which is essential for FMEA structures where a single system function (level 1) can have multiple failure modes (level 2) and each failure mode can have multiple causes and mitigation tasks. diagram Each level has a controlColumn property (default: systemItemId) that determines the grouping field for that level. When consecutive rows share the same value in a control column, Risksheet merges those cells vertically. Key merging behaviors include:
  • Empty cells act as boundaries. If a control column cell is empty, it stops merge propagation, preventing unrelated groups from merging together.
  • Downstream columns merge differently. Task and downstream columns have their own merge logic, tracking both the master item and the specific task ID.
  • Multi-item link columns require valid JSON array format to participate in merging. Empty brackets or invalid JSON prevent merging.
  • Multi-enum columns are converted to string representations for merge comparison. Cells with identical selections merge properly.
Levels with showInMenu set to true (the default) appear in the context menu for creating new items at that level.

​
The One-Document Constraint

Each Risksheet instance visualizes exactly one Polarion LiveDoc document. The grid shows only the work items contained within (or linked to) that specific document. Risksheet cannot aggregate items from multiple documents or automatically route items based on document names.
Risksheet does not support pulling risk items from multiple source documents into a single grid view. If you need cross-document visibility, use Polarion’s built-in reporting tools or consider organizing your risk items within a single document.
This constraint ensures clear data boundaries and simplifies configuration: each document carries its own risksheet.json configuration file as an attachment, defining the columns, formulas, styles, and data types specific to that risk analysis. Risksheet uses Polarion work item links to establish relationships between items: Upstream links connect risk items to their source requirements, design elements, or functions. These are configured through item link columns (itemLink or multiItemLink type). Upstream items can be loaded from other projects and documents via typeProperties configuration, allowing cross-project traceability. However, Risksheet cannot auto-populate rows with existing items from other documents — the sheet starts empty and items must be created or manually linked. Downstream links connect risk items to mitigation tasks, verification activities, or control measures. These are configured through the dataTypes.task section with role-based link filtering. The dataTypes.task.role property specifies the link role connecting tasks to risk items. The dataTypes.task.showInMenu property (default: true) controls whether task creation options appear in the context menu. The link role determines which relationship type connects the items. When configuring item link columns, the isBackLink property controls whether the system follows forward links or backlinks from the source item.

​
Task Grouping and Downstream Items

Tasks belonging to the same parent risk item are grouped together in the grid using the systemItemId field. When you add a new task to a risk item, Risksheet:
  1. Creates the task as a new Polarion work item with a temporary ID
  2. Establishes a link relationship using the configured role
  3. Groups the task row immediately after the last existing task for that parent
This grouping ensures that related tasks always appear together in the grid, regardless of their creation order. Task unlinking (removing the relationship without deleting the work item) is supported through composite IDs that identify both the parent risk item and the task. Cross-project downstream items are supported using the project/itemId format. The system detects project-less IDs and qualifies them with the appropriate project when operating across project boundaries.

​
Mandatory Fields and Data Entry

Risksheet intentionally does not enforce Polarion mandatory field rules during data entry. This design decision simplifies the risk entry workflow — engineers can create items quickly and fill in details incrementally. Mandatory field validation is intended to be enforced at later workflow status transitions.
Use cellDecorators and styles to highlight columns that correspond to required fields. Apply a colored background to visually alert users that a field needs attention, even though the system does not block saving. See Cell Decorators for configuration details.

​
Data Types Configuration

The dataTypes section controls work item type settings for risk items and tasks:
PropertyDefaultDescription
dataTypes.risk.type(none)Work item type for risk items, evaluated through dynamic expressions
dataTypes.risk.role(none)Link role for risk relationships, evaluated through dynamic expressions
dataTypes.risk.removeStrategydeleteHow risk items are removed: delete permanently or alternative method
dataTypes.risk.rejectedActionrejectWorkflow action to execute when a risk item is rejected during review
dataTypes.risk.rejectedStatusrejectedStatus value to set when a risk item is rejected
dataTypes.risk.rejectedResolutioninvalidResolution value to set when a risk item is rejected
dataTypes.task.type(none)Work item type for downstream tasks
dataTypes.task.role(none)Link role for task relationships
dataTypes.task.showInMenutrueShow task creation in the context menu
Risksheet also supports configuring multiple downstream types for scenarios where risks link to different kinds of corrective actions (for example, both design changes and verification tasks).

​
Enums and Ratings

Drop-down columns use enumeration values defined in the enums and ratings sections of risksheet.json. Both work similarly — each entry has an id, name, optional description, and optional icon. The key distinction:
  • enums — General-purpose enumeration definitions used with enum:<enumId> and multiEnum:<enumId> column types
  • ratings — Risk-specific rating enumerations used with rating:<ratingId> column types. Rating columns show the description property in dropdowns, while standard enum columns do not.
The relations array defines dependencies between enumerations for cascading selection behavior. When a parent enum value changes, child enum dropdowns automatically refresh their available options based on the defined relationship mappings.

​
Transaction Model and Data Integrity

All data operations in Risksheet are wrapped in Polarion transactions. When you save changes, the system:
  1. Begins a transaction
  2. Processes all create, update, and delete operations
  3. Maps temporary client-side IDs (prefixed with *) to permanent Polarion IDs
  4. Commits the transaction on success, or rolls back on failure
This transactional approach ensures data consistency. If any part of a save operation fails, the entire batch is rolled back, preventing partial updates that could leave your data in an inconsistent state. Both PATCH (partial update) and PUT (full update) operations are supported.

​
Referenced and Branched Items

Risksheet supports referenced work items from branched documents. When branchingSupport is enabled (true), branched documents can display referenced items from the original document as read-only entries. These referenced items appear with special indicators in the grid and can optionally be made editable with editableReferencedWorkItems=true. Referenced items can also be converted to local copies through the context menu “Overwrite Row Item” action, which changes the reference type from reference to overwrite, allowing local modifications to be saved back.
Referencing risks across multiple non-branched documents is not currently supported. For cross-document risk referencing, use the branching support feature or Polarion’s native cross-project linking capabilities.

​
OData and API Access

Because Risksheet data is stored as standard Polarion work items, all risk data is accessible through the OData API layer. The data service supports grid item retrieval for a specific document (with optional revision/baseline parameters), linked item retrieval with filtering for autocomplete suggestions, work item creation with automatic temporary-to-permanent ID mapping, work item updates, and deletion with task unlinking. For OData endpoint details, see OData API Endpoints.

​
Further Reading

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