> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # What is Risksheet? > Nextedy RISKSHEET is a generic spreadsheet-like interface for managing structured work item collections inside Siemens Polarion ALM. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; The simplest mental model: **think of what you used to do in Excel, but inside Polarion**. Same familiar tabular editing experience — rows, columns, cell merging, formulas, conditional formatting — but every cell is backed by a real Polarion work item field, with full traceability, versioning, permissions, and audit history built in. Risksheet turns a Polarion LiveDoc into an interactive, methodology-aware grid where each row is a work item, each column is a field or computed value, and the whole structure is driven by a sheet configuration. ## The Problem Risksheet Solves Risk analysis, traceability matrices, and compliance assessments share a structural pattern: a table where each row represents a structured record (a failure mode, a hazard, a requirement, a threat), each column captures a specific property (severity, occurrence, mitigation, parent function), and certain columns are computed from others (RPN = severity × occurrence × detection). Historically, organizations have solved this in two ways: 1. **Spreadsheets** (Excel, Google Sheets) — familiar and flexible, but disconnected from the rest of the engineering lifecycle. No traceability to requirements, no link to design or test artifacts, no formal review history, no enforced workflow, and frequent versioning chaos. 2. **Generic ALM tables** — traceable and versioned, but row-oriented editing is slow, formulas are weak or non-existent, conditional formatting is limited, and hierarchical analyses (failure mode → cause → effect) become awkward. Risksheet is designed to give you the **Excel-like editing experience** for tabular analysis **without leaving Polarion**. The data lives in Polarion work items — subject to Polarion authorization, fully traceable, fully versioned — while the user interacts with a fast, formula-aware, hierarchical grid. diagram Risksheet is **not a separate database**. There is no parallel store, no syncing layer, no risk of the grid drifting from the system of record. Every value the user types lands directly on a Polarion work item field, governed by Polarion's permissions and captured in Polarion's revision history. ## A Methodology-Agnostic Tool A common misconception — reinforced by demos and marketing — is that Risksheet is "for FMEA" or "for HARA". It is not. Risksheet is a generic tool supporting any risk management methodology, including FMEA, HARA, TARA, STRIDE, and CVSS. The methodology comes from the **sheet configuration**: the columns you define, the formulas you write, the levels you organize, and the styling rules you apply. Because Risksheet does not constrain methodology, Nextedy ships **solution templates** for typical methodologies across industries: | Industry | Typical methodology | What the template provides | | ----------------------------- | -------------------------- | ---------------------------------------------------------------------------------- | | Automotive (ISO 26262) | DFMEA, HARA, ASIL | Severity / occurrence / detection scales, ASIL classification, mitigation tracking | | Medical devices (ISO 14971) | Risk management file | Hazard / harm structure, risk control measures, residual risk assessment | | Industrial safety (IEC 61508) | Functional safety analysis | SIL determination, safety function decomposition | | Aerospace | FHA, PSSA, SSA | Function / failure condition / detail levels, classification | | Cybersecurity (ISO/SAE 21434) | TARA, STRIDE, CVSS | Threat, vulnerability, attack tree, CVSS scoring | You start from a solution template that matches your industry and methodology, then adapt the columns, formulas, and scales to your organization's process. You do not start from a blank configuration. The two underlying entity slots — internally called "risk" and "task" — are abstract. They can hold any two Polarion work item types. A "risk" can be a requirement; a "task" can be a test case. With this configuration Risksheet becomes a requirements traceability matrix or a V\&V matrix. The name "Risksheet" reflects the most common use case, not the limit of the tool. ## What Is Risk Management, Briefly? Risk management — as practiced under ISO 14971, ISO 26262, IEC 61508, ISO/SAE 21434, and similar standards — is a structured process of identifying things that could go wrong, evaluating how bad and how likely they are, deciding what to do about them, and proving that the residual exposure is acceptable. The process is broadly the same across standards, even when the terminology differs: 1. **Identify** items, functions, hazards, threats, or failure modes that could harm safety, security, mission, or business. 2. **Analyze** each one by assigning ratings — typically severity, occurrence/likelihood, and detectability — drawn from a defined scale. 3. **Score** the combined risk (an RPN, ASIL, SIL, CVSS value, or qualitative classification). 4. **Mitigate** unacceptable risks by adding controls, design changes, requirements, or tests. 5. **Reassess** after mitigations to confirm residual risk is acceptable. 6. **Trace** every risk to its source (function, requirement, hazard) and every mitigation to its evidence (task, test, design). 7. **Review and approve** the analysis as a controlled, audited artifact. Risksheet does not enforce any particular vocabulary or scoring formula. It provides the **grid, the formulas, the levels, the styling, and the traceability** that all of these methodologies happen to need. The specific columns ("ASIL", "Severity\_S2", "Hazard", "CVSS\_Vector") and the specific formulas (`RPN = S × O × D`, ASIL lookup tables, CVSS calculators) live in the sheet configuration. ## How Risksheet Works — The Mental Model There are five core ideas that make Risksheet feel coherent once you see them together. ### 1. The Grid Is a View Over Polarion Work Items Each row in a risksheet is a Polarion work item. The work item's type, fields, links, and permissions are defined in Polarion. The grid simply **renders** these as cells and lets the user edit them. When you change a cell value, Risksheet updates the work item field. When you save, Polarion writes a new revision. There is no separate store. This is the most important architectural fact: Risksheet visualizes and edits Polarion data — it does not store data separately. ### 2. Columns Are Defined Per-Document Each LiveDoc that uses Risksheet has its own **sheet configuration** describing which columns appear, what they bind to, how they are styled, and how they compute. The configuration covers: * Which Polarion field each column reads (`bindings`) * The column type (enum, rating, text, number, item link, formula) * Headers, widths, header groups * Default sort order and saved column visibility presets (called **views**) * Named formulas that calculate derived values like RPN * Named cell decorators that apply conditional CSS styling A typical risksheet has many columns — input fields the user fills in, computed columns showing derived values, and link columns pointing to upstream requirements or downstream mitigation tasks. See [Architecture](/risksheet/concepts/architecture) for how this configuration is delivered and merged across documents and templates. ### 3. Visual Levels Group Rows by Cell Merging In an FMEA, an "Item" can have many "Failure Modes", and each Failure Mode can have many "Causes". A naive grid would repeat the Item text on every row — visually noisy and error-prone. Risksheet uses **levels** (a configuration concept) to merge cells: when consecutive rows share the same Item value, the Item cell is merged into one tall block; when they share the same Failure Mode, that cell is merged at the next level down. diagram A crucial subtlety: **visual levels and data model levels are different**. The data model has exactly two slots — main row items and downstream linked items. Visual levels (1, 2, 3, …) are presentation concepts achieved through cell merging. Every row in the FMEA above can be the same Polarion work item type; the visual hierarchy comes from which column values happen to repeat. See [Data Model and Work Items](/risksheet/concepts/data-model) for the full mechanics of work item visibility and levels. ### 4. Formulas Compute Derived Values Most risk methodologies involve computed values. A classic example is the Risk Priority Number: > RPN = Severity × Occurrence × Detection In Risksheet, this is a named formula in the sheet configuration. A column references the formula and Risksheet recomputes the value when any input changes. Formulas are written in JavaScript and receive the row data; they can express anything from simple multiplication to ASIL lookup tables, CVSS calculators, or qualitative classification logic. Computed values are typically **paired with cell decorators**: small functions that apply CSS classes based on the value. Low RPN gets a green background; high RPN gets red. This produces the familiar "traffic light" risk view without manual cell coloring. For regulated environments, the recommended pattern is to keep the sheet configuration declarative (column structure, references to named formulas) and externalize complex calculations — risk matrices, multi-field classifiers, conditional formatting helpers — into the **top panel configuration** (a Velocity template displayed above the grid). The sheet configuration then contains thin wrappers like `function(info){ return getInitialRE(info); }`. This separates auditable structure from custom logic and shrinks the validation scope when matrices change. ### 5. Traceability Is Built In Every Risksheet row is a Polarion work item, so every Polarion link is available. Risksheet exposes this in two directions: * **Upstream** — a column can show a linked requirement, function, hazard library entry, or any other reference work item. Typically these columns are read-only displays of properties from the linked item. * **Downstream** — separate "task" rows below a risk represent mitigations, safety requirements, controls, or test cases. They are real Polarion work items linked via a configured link role. The combination of declarative columns plus configured task links means each risk analysis is **automatically a traceability artifact**. There is no separate "trace matrix" step. diagram See [Traceability and Linking](/risksheet/concepts/traceability) for the link role configuration and the upstream library pattern. ## Common Misconceptions Several patterns of confusion appear consistently in support discussions. Clearing them up early prevents structural mistakes. A risksheet is **the visual representation of a single Polarion LiveDoc**. It cannot aggregate work items from multiple documents or route items between documents based on naming conventions. If you need a combined view across several analyses, that is a Polarion-level concern (a wiki page, a saved query, or a separate "summary" document). It is not something Risksheet does. Risksheet and Nextedy POWERSHEET are different products with different goals. Risksheet is the **risk analysis grid** with levels, formulas, ratings, and the risk/task two-entity model. Powersheet is a more general-purpose work item table tool. If a customer needs FMEA, HARA, TARA, or any structured risk methodology with hierarchical levels and traceability to mitigations, Risksheet is the right product. New users often confuse the two. Risksheet supports three review modes — comment-based, work-item-based, and approval review. The approval review creates approval-tagged comments but does NOT trigger Polarion's formal approval state transitions (draft → reviewed → approved). If you need formal document workflow signoff, configure the Polarion document workflow separately. The approval review captures reviewer intent; the workflow state must be advanced through Polarion's document workflow. Some older guides describe top-level `ratings`, `enums`, or `relations` sections in the sheet configuration. These do not exist. Rating scales and enumerations are defined in Polarion (Administration → Enumerations) and referenced from columns via `type: rating:`, `type: enum:`, or `type: multiEnum:`. Dependent enumerations are a column-level feature, not a separate section. If you see those sections in a config, they are ignored by the engine. ## How Configuration Reaches a Document Each LiveDoc loads a sheet configuration. The configuration can come directly from the document, or it can be inherited from a global template attached to the document. Template inheritance is what makes solution templates effective: an administrator maintains the canonical FMEA template centrally, and every new FMEA document picks up its columns, levels, formulas, and styles automatically. For deeper detail on where configuration files live, how template inheritance works, and how the three configuration files relate to each other (sheet configuration, top panel, PDF export), see: * [Architecture](/risksheet/concepts/architecture) * [Configuration Hierarchy](/risksheet/concepts/configuration-hierarchy) ## Where Risksheet Fits in the Polarion Picture | You can use Polarion for… | Risksheet adds… | | ---------------------------------------------- | ----------------------------------------------------------------------------- | | Storing requirements, tests, design work items | A grid-shaped editing surface for structured analyses | | Linking work items across artifacts | Configured upstream and downstream link columns within the grid | | Workflow on documents | Risksheet-internal review modes plus standard document workflow | | Exporting LiveDoc documents to PDF | Custom PDF export configuration tuned to risk-table layouts | | Querying work items with Lucene | Saved views (column visibility presets) and queryFactory-backed autocompletes | Risksheet does not replace any of Polarion's core capabilities — it gives risk-analysis-style work the editing surface that pure work item editing lacks, while keeping the data inside Polarion. ## Choosing the Right Risksheet Workflow | If your goal is… | Start here | | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Build a working FMEA / HARA / TARA from a template | [Risk Management Guides](/risksheet/guides/risk-management/index) | | Understand columns, levels, and formulas before editing config | [Configuration Hierarchy](/risksheet/concepts/configuration-hierarchy) and [Data Model and Work Items](/risksheet/concepts/data-model) | | Configure upstream and downstream traceability | [Traceability and Linking](/risksheet/concepts/traceability) | | Set up review and approval | [Review Workflows](/risksheet/concepts/review-workflows) | | Look up exact column properties and formula syntax | [Reference](/risksheet/reference/index) | | Find the JSON shape of a specific feature | [Configuration Reference](/risksheet/reference/configuration/index) and [Configuration Examples](/risksheet/reference/examples/index) | | Export to PDF or Excel | [Export Guides](/risksheet/guides/export/index) | | Diagnose a problem with your risksheet | [Troubleshooting](/risksheet/troubleshooting/index) | ## Summary Risksheet is best understood as **the spreadsheet experience for Polarion-tracked structured analyses** — methodology-agnostic, configuration-driven, traceability-native, and grounded in real Polarion work items. Methodology (FMEA, HARA, TARA, STRIDE, CVSS, requirements traceability, V\&V matrices) is a function of configuration, not a property of the tool. Solution templates ship the typical configurations so you can start from a known-good baseline and tailor it to your process rather than starting from scratch. What is constant across every Risksheet deployment is the foundation: * **One LiveDoc, one risksheet, one configuration** * **All data lives in Polarion work items** with full permissions, history, and audit * **The grid is a view**, not a separate database * **Columns, formulas, levels, and decorators are declarative** in the sheet configuration * **Traceability is intrinsic** — upstream and downstream links are columns, not afterthoughts * **Methodology is configurable** — the same engine produces FMEA, HARA, TARA, CVSS, or a generic traceability matrix depending on how it is set up To go deeper into how the pieces fit together architecturally, continue to [Architecture](/risksheet/concepts/architecture). To start using Risksheet on a real document, see [Getting Started](/risksheet/getting-started/index).