> ## 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.
# Powersheet vs. Risksheet
> How Nextedy POWERSHEET and Nextedy RISKSHEET differ, when to use each, and how the two complement each other 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}
;
};
**Goal:** Understand the key differences between Powersheet and Risksheet, when to use each product, and how they complement each other.
Nextedy offers two interactive grid products for Siemens Polarion ALM: **Powersheet** and **Risksheet**. Both render a spreadsheet-like editing experience directly inside Polarion, and both store their data as standard Polarion work items -- but they solve different problems and are configured in fundamentally different ways.
## Core Purpose
**Powersheet** is a general-purpose hierarchical sheet extension for Polarion. It is designed to manage any structured, multi-level data model -- requirements traceability, test planning, task boards, custom domain models -- across any domain or industry. You define what data to show and how to structure it through YAML configuration files.
**Risksheet** is purpose-built for risk analysis workflows. It targets safety engineers and cybersecurity analysts performing FMEA, HARA, TARA, STRIDE, or CVSS assessments in regulated industries such as automotive (ISO 26262), medical devices (ISO 14971), and cybersecurity (ISO/SAE 21434). It includes risk-specific capabilities -- risk rating scales, RPN formulas, risk matrices, and risk review workflows -- that are not present in general-purpose grids.
## Shared Foundation
Despite their different goals, the two products rest on the same Polarion-native foundation, which is why they complement each other so cleanly:
* **Native Polarion work items and links.** Neither product keeps a separate datastore. Every row, and every relationship between rows, is a standard Polarion work item or link -- so the data inherits Polarion versioning, audit history, permissions, queries, and suspect-link propagation, and stays visible in the Polarion tracker.
* **Polarion-inherited security.** Both authenticate through Polarion and enforce project roles and field-level permissions on the server, regardless of what the grid shows on the client.
* **SVN-stored configuration with instant deployment.** Both keep their configuration in the project's SVN repository and apply changes the next time a sheet is opened -- no build step and no server restart.
## Configuration Model
This is the most significant architectural difference between the two products.
### Powersheet: three-layer YAML architecture
Powersheet separates its configuration into three distinct layers:
1. **Data model** -- A YAML file that defines the semantic layer: which Polarion work item types, link roles, and document types are exposed as structured entity types and relationships. The data model also enforces process constraints such as link cardinality rules.
2. **Sheet configuration** -- A separate YAML file that defines how the data model data is displayed: which columns appear, how rows expand to show related entities, which views are available, and how editing behaves.
3. **Document entry point** -- A Polarion LiveDoc that references a sheet configuration. One sheet configuration can be reused across many documents and even across projects with different Polarion type IDs (as long as each project has its own data model mapping).
This separation means you can standardize a single sheet layout across an entire organization and adapt it to local Polarion configurations purely by adjusting the data model -- without touching the sheet configuration.
The data model is a semantic abstraction layer: entity types and relationships carry their own names and map onto Polarion work item types and link roles -- a single entity type can even span several Polarion types. Powersheet resolves columns, queries, pickers, and validation through this vocabulary rather than against raw Polarion type IDs, which is what makes one sheet configuration portable across projects.
### Risksheet: single JSON configuration per document
Risksheet is configured through a `risksheet.json` file attached directly to each LiveDoc document (or inherited from a template document). This single JSON file controls the entire grid: columns, JavaScript formulas, cell decorators, CSS styles, enumeration dropdowns, hierarchical row levels, and link role bindings.
The configuration-driven design makes Risksheet highly flexible within the risk analysis domain, but it is intentionally scoped to that domain. There is no concept of a separate data model layer.
## Data Scope
**Risksheet** roots each grid in a **single Polarion LiveDoc** -- its main (row) work items all come from that one document, and it cannot aggregate root data across documents. It can, however, still display *linked* items one level up (upstream references) and one level down (mitigation and task items), and those linked items may live in other documents.
**Powersheet** supports **expansion paths** -- configuration-defined traversals that follow link roles to pull in related entities from across the data model. A single powersheet can display a root entity alongside its linked children, traceability targets, and associated test cases in one view, even when those entities span different document types.
## Typical Use Cases
| Scenario | Recommended Product |
| ----------------------------------------------------------- | ------------------------------------------------- |
| FMEA, HARA, TARA, STRIDE, or CVSS analysis | **Risksheet** |
| Requirements traceability matrix (RTM) | **Powersheet** |
| System decomposition and allocation | **Powersheet** |
| Multi-level task and planning boards | **Powersheet** |
| Risk register integrated with broader traceability | **Powersheet** (with risk data model) or **both** |
| Audit-ready risk analysis with RPN and color-coded matrices | **Risksheet** |
## Capability Comparison
The table below compares the two grids feature by feature. A check (✓) means the capability is available today; a dash (—) means it is not yet supported. The **Mid-term roadmap** column flags gaps that are planned for an upcoming release.
| Capability | Risksheet | Powersheet | Details | Mid-term roadmap |
| ------------------------------------------ | :-------: | :--------: | ---------------------------------------------------------------------------------------------------- | :--------------: |
| Excel-like editing | ✓ | ✓ | | |
| Filtering | ✓ | ✓ | | |
| Searching | ✓ | ✓ | | |
| Single work item picker | ✓ | ✓ | | |
| Multi work item picker | ✓ | ✓ | | |
| Deep structures (more than two levels) | — | ✓ | Risksheet can go only one level deep; Powersheet can manage data from any number of levels. | |
| Multi-dimension | — | ✓ | Risksheet shows linked items one level up and down; Powersheet can add references at any depth. | |
| Enum | ✓ | ✓ | | |
| Multi-enum | ✓ | — | Powersheet does not yet support multi-enum custom fields. | ✓ |
| Manage workflow status | ✓ | — | Powersheet does not yet support changing workflow status. | ✓ |
| Compare | ✓ | — | Powersheet can open data from a revision; baseline compare is not available yet. | |
| Export to PDF | ✓ | — | Powersheet cannot export to PDF yet. | ✓ |
| Export to Excel | ✓ | ✓ | | |
| Merge based on cell value | ✓ | — | Powersheet structure is derived from work items, not yet value-driven merged cells. | |
| Granular permissions | ✓ | ✓ | | |
| Data from multiple documents at root level | — | ✓ | Risksheet shows root (row) work items from a single document only. | |
| Review mode for changes before save | — | ✓ | Powersheet presents local unsaved changes before they are committed. | |
| Review comments (approvals) | ✓ | — | Powersheet does not yet provide a review mode for content approval. | |
| Data routing | — | ✓ | Powersheet can automatically pick the right target document based on data constraints. | |
| Computed / formula columns | ✓ | ✓ | Risksheet evaluates JavaScript formulas (RPN, ASIL, CVSS); Powersheet uses dynamic expressions. | |
| Server-rendered columns | ✓ | ✓ | Read-only columns rendered by Velocity templates that can traverse links and call Polarion services. | |
| Saved views / perspectives | ✓ | ✓ | Named column-visibility presets, switched without reloading data or losing edits. | |
| Conditional cell styling | ✓ | ✓ | Value-driven cell styling -- Risksheet cell decorators, Powersheet formatters. | |
**Two senses of "review."** The two products use the word *review* for different things. Powersheet's review mode previews local unsaved changes before they are committed, whereas Risksheet's review features support content approval -- comment-based, work-item-based, or approval-based workflows. They solve different problems and are not equivalent.
## Licensing and Integration
Risksheet and Powersheet are **licensed independently**, and each is fully functional on its own -- neither product requires the other. Owning both does not mean paying for Active Users twice: Active Users are counted once across the two products, and read-only access to the second product is covered by its bundled Connect license.
Each product is complete on its own -- you are not missing core functionality by running just one. When both are installed and Powersheet holds a valid production license, Risksheet transparently switches to an enhanced configuration that **adds** extra capabilities on top of what it already does -- no manual configuration required, and evaluation or trial Powersheet licenses do not trigger it. Owning both mainly opens up more possibilities and changes how licensing is applied; it does not switch on features that were otherwise missing.
## Summary
| | Powersheet | Risksheet |
| -------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------ |
| **Primary use case** | General-purpose hierarchical data management | Risk analysis (FMEA, HARA, TARA, STRIDE, CVSS) |
| **Configuration format** | YAML (data model + sheet config) | JSON (`risksheet.json`) |
| **Configuration layers** | Three (data model, sheet config, document) | One (document-attached JSON) |
| **Cross-document data** | Yes, via expansion paths | Root rows from one document; linked items may span documents |
| **Risk-specific features** | No (general columns only) | Yes -- RPN formulas, risk rating scales, risk matrices, review workflows |
| **Config reuse** | Single sheet config shared across many documents | Template inheritance via template documents |
| **License** | Separate | Separate |
| **Runtime integration** | Adds extra Risksheet capabilities when both are licensed | Benefits from Powersheet when both are licensed |
If your primary need is structured risk analysis with industry-standard rating scales and calculated risk metrics, start with **Risksheet**. If you need a flexible, model-driven grid for managing any type of Polarion work item relationships -- including but not limited to risk -- start with **Powersheet**.
## See Also
* [Migrate from Risksheet to Powersheet](/powersheet/guides/migration/migrate-from-risksheet) -- Step-by-step transition of an existing project, converting the data model, sheet configurations, and document bindings
* [Data Model vs Sheet Configuration](/powersheet/concepts/data-model-vs-sheet-config) -- The configuration separation that underpins Powersheet's flexibility
* [Core Components](/powersheet/concepts/core-components) -- The building blocks of every powersheet