What is Risksheet?

​

The Problem Risksheet Solves

Regulated industries such as automotive (ISO 26262), medical devices (ISO 14971), industrial safety (IEC 61508), and cybersecurity (ISO/SAE 21434) require structured risk analysis as part of their development processes. Teams performing FMEA, HARA, or TARA analyses typically face a fundamental tension: they need the familiar, tabular layout of a spreadsheet for efficient data entry, but they also need the traceability, version control, and workflow management capabilities of an ALM tool. Without Risksheet, teams often resort to one of two unsatisfying approaches:

• External spreadsheets (Excel, Google Sheets) that provide a familiar grid interface but lack traceability to requirements, lose version history, and cannot enforce workflows or permissions. Risk data lives outside the ALM system, creating a synchronization burden and compliance gaps.
• Native Polarion tables embedded in LiveDoc documents that maintain traceability but provide a poor editing experience for the dense, multi-column layouts that risk analysis demands. Navigating hundreds of risk items through standard Polarion work item forms is slow and error-prone.

Risksheet eliminates this trade-off. It renders a full-featured interactive grid inside a Polarion LiveDoc page, where each row is a Polarion work item and each column maps to a work item field. You get the spreadsheet experience safety engineers expect, with the ALM capabilities compliance auditors require.

​

How Risksheet Fits into Polarion

Risksheet is deployed as a Polarion server plugin. It does not replace or modify Polarion’s core data model. Instead, it provides an alternative rendering and editing interface for work items that already exist within Polarion LiveDoc documents. The key architectural principle is that Risksheet stores no data of its own. All risk items, tasks, and traceability links are standard Polarion work items stored in Polarion’s repository. Risksheet reads these work items, renders them in a grid, and writes changes back through Polarion’s standard APIs. This means:

• Work items edited in Risksheet are immediately visible in Polarion’s native work item views, and vice versa.
• All Polarion features --- version history, baselines, branching, permissions, workflows --- apply to data created or modified through Risksheet.
• Removing Risksheet from a Polarion instance does not affect the underlying work item data.

​

Core Architecture

Risksheet consists of two main components that work together: Server-side plugin --- Deployed on the Polarion server, this component handles configuration loading, data retrieval, enumeration resolution, PDF export rendering, and Velocity template processing. It exposes HTTP endpoints that the client-side grid communicates with, including /api/config for configuration, /api/document for document metadata, and /api/pdfscript for PDF export generation. Client-side grid --- A JavaScript-based interactive grid that renders within the browser when you open a Risksheet-enabled LiveDoc document. The grid provides Excel-like editing, inline formula evaluation, conditional cell formatting, autocomplete for linked items, and context menu operations. All user interactions happen in the browser, with save operations writing changes back to the Polarion server. Configuration is stored in a risksheet.json file attached to each LiveDoc document (or inherited from a template). This JSON file defines the entire grid structure: which columns appear, how cells are formatted, what formulas calculate, which enumerations populate dropdowns, and how risk items link to downstream tasks.

​

One Document, One Risksheet

A fundamental design constraint to understand: each Risksheet instance represents exactly one Polarion LiveDoc document. The grid displays the work items contained within that single document, organized according to the document’s hierarchy and the risksheet.json configuration. Risksheet cannot aggregate work items from multiple documents or automatically route items between documents based on naming conventions or other criteria. If you need to see risk items from several documents in one view, you would use Polarion’s native querying capabilities or cross-project linking features rather than expecting a single Risksheet instance to span multiple documents.

​

Configuration-Driven Design

Almost every aspect of Risksheet’s behavior is controlled through the risksheet.json configuration file. Rather than providing a fixed set of columns or a rigid FMEA template, Risksheet exposes a rich configuration schema that lets you define exactly the grid layout you need. The configuration system supports:

• Column definitions --- Specify which Polarion fields appear as columns, their display types (text, enum, multi-enum, item link, task link, calculated, server-rendered), widths, headers, and grouping.
• Formulas --- JavaScript functions that compute derived values such as Risk Priority Numbers (RPN) from severity, occurrence, and detection ratings.
• Cell decorators --- JavaScript functions that apply conditional CSS styling to cells based on their values, enabling color-coded risk levels.
• Styles --- CSS class definitions that the cell decorators reference, controlling background colors, text colors, and font weights.
• Enumerations and ratings --- Custom dropdown options for enum columns and risk rating scales with ID, label, and description fields.
• Hierarchical levels --- Multi-level row structures for failure mode/cause/effect groupings with cell merging and expand/collapse navigation.
• Data types --- Configuration for risk items and task items, including work item types, link roles, query factories, and menu visibility.
• Views --- Saved column visibility presets that let you switch between different analysis perspectives without modifying the configuration.

This configuration-driven approach means Risksheet is not limited to a single risk methodology. The same engine powers FMEA tables with severity/occurrence/detection columns, HARA tables with ASIL classification, TARA tables with threat/vulnerability analysis, STRIDE tables for cybersecurity assessment, and CVSS scoring matrices. The difference between these use cases is entirely in the configuration, not in the software. For details on the configuration file format, see Configuration System and the Risksheet.json Format reference.

​

Template Inheritance

To avoid duplicating configuration across dozens of documents, Risksheet supports template inheritance. You define a master risksheet.json in a Polarion template document, and individual LiveDoc documents inherit that configuration automatically. When you update the template, all inheriting documents pick up the changes. Documents can also override their inherited template to create a document-specific configuration that is independent of the global template. This is useful when a particular risk analysis requires custom columns or formulas that do not apply to other documents in the project. The inheritance hierarchy resolves in this order: document attachment (highest priority), template document, then project-level global template. See Configuration Hierarchy for the full resolution chain.

​

Key Capabilities at a Glance

​

Risksheet vs. POWERSHEET

Users new to the Nextedy product line sometimes ask how Risksheet differs from POWERSHEET. The distinction is straightforward:

• Risksheet is specifically designed for risk analysis workflows (FMEA, HARA, TARA, STRIDE, CVSS). It includes risk-specific features such as risk rating scales, RPN formulas, risk matrices, and risk review workflows.
• POWERSHEET is a general-purpose spreadsheet grid for Polarion that supports broader use cases such as requirements management, test planning, and traceability matrices. It uses the same underlying grid technology but with a different feature set and configuration model.

When both products are installed and POWERSHEET has a valid production license, Risksheet automatically unlocks additional features from the POWERSHEET capability set. This integration is automatic and requires no manual configuration. Evaluation or trial POWERSHEET licenses do not enable these enhancements.

​

Supported Risk Methodologies

Risksheet is methodology-agnostic by design. The same grid engine supports multiple risk analysis approaches through configuration: Each methodology maps to a specific set of columns, enumerations, formulas, and cell decorators in the risksheet.json configuration. The Getting Started section provides tutorials for setting up your first Risksheet with common FMEA and HARA configurations.

​

What Risksheet Does Not Do

To set clear expectations, Risksheet does not:

• Replace Polarion’s work item system --- Risksheet is a visual interface, not a separate data store. All data lives in Polarion.
• Aggregate multiple documents --- Each Risksheet view corresponds to one LiveDoc document.
• Perform automated risk assessment --- Risksheet calculates formulas and applies formatting, but risk ratings are entered by human analysts.
• Provide standalone operation --- Risksheet requires a running Polarion server instance. It cannot operate outside of Polarion.

​

Next Steps

• Architecture --- Understand the technical components and data flow in detail
• Data Model and Work Items --- Learn how risk items map to Polarion work items
• Configuration System --- Explore the risksheet.json configuration model
• Create Your First Risksheet --- Follow a hands-on tutorial to build an FMEA table

Sources

KB Articles

• What Work Items are visible on the Risksheet and understanding levels
• How to install Risksheet into existing project Drive pilot
• Risksheet Document Config File - risksheet - format reference

Support Tickets

• #6694
• #6862
• #6412

Source Code

• risksheet.json
• RisksheetProjectProperties.java
• DefaultTraceProvider.java
• AddTaskCommand.ts
• AppConfig.ts