Skip to main content
Whether you are adopting Risksheet for the first time or moving an existing analysis to a new version, begin from one of the Nextedy solution templates that matches your methodology (FMEA, HARA, TARA, STRIDE, CVSS). Templates carry verified columns, levels, dataTypes, formulas, cellDecorators, and styles sections. Modify a template to match your process rather than authoring a sheet configuration from a blank file. See Configuration Examples and the Templates reference.
A Risksheet upgrade replaces the server-side Polarion plugin and the client-side grid renderer. Your existing sheet configurations, top panel templates, PDF export templates, and Polarion work items are not modified by the upgrade. New configuration properties become available to use, but documents continue to function with their existing configuration until you opt in.
In most cases no. Risksheet upgrades aim to be backwards-compatible — existing columns, levels, dataTypes, formulas, cellDecorators, and styles continue to work. Migration is typically needed only when you want to adopt a new property (for example createInDocument or linkToRisksheet) or fix a property name that was previously misspelled. See Configuration Management for the recommended workflow.
From version 25.5.0 onward, the configuration editor supports YAML editing with syntax highlighting, error detection, and history. Open the document menu and choose Menu > Configuration > Edit Risksheet Configuration. The underlying file remains the sheet configuration (risksheet.json) — the editor presents it as YAML so the file is easier to read and review.
diagram
Newer properties can be added incrementally to an existing sheet configuration once the server has been upgraded to the required version. Examples include createInDocument for choosing where new tasks are created, linkToRisksheet on dataTypes.task for subsheet navigation, and dependent enums at the column level. Add only the properties you need and leave the rest of the configuration unchanged.
After adding a new property, open the document in Polarion and confirm the grid behaves as expected before rolling the change out to templates and child documents.
By far the most common is the column property bindings (plural). Some older or hand-edited configurations contain binding (singular), which silently fails because the column never resolves a Polarion field. When you migrate, search every columns entry and confirm the property is bindings: <fieldId>. The reference for column properties is in Column Types and Fields.
Remove them. Those three top-level sections do not exist in the real Risksheet engine — the engine ignores them entirely. Rating scales and enumerated values are defined as Polarion enumerations in Administration > Nextedy Risksheet > Setup and referenced from columns via type: rating:<enumId>, type: enum:<enumId>, or type: multiEnum:<enumId>. Dependent enums are a column-level feature available from v25.3.1, not a top-level configuration section.
A document inherits configuration from its template at the point of creation and on subsequent Refresh from Template actions. After an upgrade, you can update a template first, validate it on a sandbox document, and then propagate the change to existing documents at your own pace. Because all data lives in Polarion work items and not in a Risksheet-private store, refreshing a configuration never moves or rewrites your risk items. See Templates and Configuration Management.
The licensing tier affects what users can do, not how Risksheet is configured. Three tiers are supported: ALM, Requirements, and QA licenses provide full create-and-modify access; the PRO license can modify existing Risksheet rows but cannot create new ones; the REVIEWER license is read-only. See Licensing and the Licensing Model FAQ for details.
Older generated documentation sometimes used the property name columns for saved views — the real property name is columnIds. When migrating a views entry, rename the array to columnIds and check whether you want to use the @all shorthand or the -columnId exclude prefix:
The defaultView property (v24.1.0+) marks which view loads first when the document opens. See Saved Views under column configuration guides.
Yes — formulas and cellDecorators are evaluated client-side and are not transformed by upgrades. The recommended pattern, especially in regulated industries, is to keep formulas thin and define the heavy logic (risk matrices, multi-field conditional formatting) in the top panel configuration (risksheetTopPanel.vm). This separation keeps the sheet configuration auditable while custom logic stays under code review. See Formulas and Styling.
The configuration reference for each property notes the minimum version where applicable. Examples include editableReferencedWorkItems (v23.3.3+), checkLinkRoleCompliance (v24.2.2+), createInDocument (v24.8.1+), moduleOnlyPermissions (v24.8.5+), the dependent enum column feature (v25.3.1+), and YAML editing in the configuration editor (v25.5.0+). Before adopting a property, confirm your server is at least at the listed version. See Compatibility and Configuration.
Risksheet runs inside Polarion ALM. Always verify the Polarion version your environment runs and the Risksheet plugin version are compatible before upgrading either component. Your Polarion administrator should perform the upgrade and run a sandbox validation before changing production templates.
Last modified on June 30, 2026