Goal: Understand the key differences between Powersheet and Risksheet, when to use each product, and how they complement each other.
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:- 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.
- 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.
- 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).
Risksheet: single JSON configuration per document
Risksheet is configured through arisksheet.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
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.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
See Also
- Migrate from Risksheet to Powersheet — Step-by-step transition of an existing project, converting the data model, sheet configurations, and document bindings
- Data Model vs Sheet Configuration — The configuration separation that underpins Powersheet’s flexibility
- Core Components — The building blocks of every powersheet