Skip to main content
diagram

Column Properties

Calculated columns use the standard column properties plus the formula property that references a named formula definition.
When a column has a formula property set, the column is automatically marked as read-only. This is enforced by the configuration manager and cannot be overridden. Users see computed values but cannot edit cells in formula columns.
Cell text wrapping is controlled via CSS rules in the top-level styles section, not by column-level boolean properties. HTML rendering in cells is handled by serverRender (Velocity templates) or by the column type system, not by a boolean toggle on the column.

Formula Definitions

Formulas are defined in the top-level formulas object of the sheet configuration. Each formula is a named JavaScript function that receives an info context object and returns the computed value.

Formula Function Signature

Each formula function receives an info object: The function must return the computed value. Return null to display an empty cell.

RPN Formula Examples

The two most common formulas in FMEA risk analysis are the initial RPN and the revised (post-mitigation) RPN: Initial RPN (commonRpn):
Revised RPN (commonRpnNew):
Both RPN formulas return null when the computed value is 0 (falsy). This prevents displaying 0 in the grid when input fields have not been filled in yet. The return value?value:null pattern is the standard approach for null-safe formula results.

Cross-Type Severity References

Risk calculations can reference properties from different work item types in the hierarchy. For example, you can configure a formula to use the severity from the Risk item itself rather than from a linked Accident or Harm work item. The formula accesses the field through info.item['fieldId'] regardless of which work item type provides the value — the data binding resolves the correct source.
The exact behavior of cross-type field references depends on your data type configuration and level hierarchy. The severity source can be changed by modifying which field ID the formula references. Consult your dataTypes configuration to understand which fields are available on each work item type.

Connecting Formulas to Columns

To create a calculated column, define the formula in formulas and reference it by name in the column’s formula property:
The column id serves as the data binding. The formula property value must exactly match a key in the formulas object.

Combining Formulas with Cell Decorators

Calculated columns are frequently paired with cell decorators to apply conditional formatting based on the computed value. The cell decorator function references the formula column’s output value.
The decorator applies CSS classes based on RPN risk thresholds. Thresholds shown here are illustrative — real deployments configure them to match each organization’s risk acceptance policy: See Cell Decorators and Item Colors for complete decorator configuration reference.

Data Persistence and Export Behavior

Calculated column values are computed client-side in the browser by the JavaScript formula. The grid renders the result, but the value does not automatically exist in Polarion until it is persisted as a work item field. Because all Nextedy RISKSHEET data lives in Polarion work items — Risksheet does not maintain a separate data store — persistence to Polarion is required for the value to participate in audit trails, queries, exports, and downstream traceability.

Client-Side Computation, Server-Side Audit

For regulated workflows (ISO 26262, ISO 14971, IEC 61508, ISO/SAE 21434), the calculated value MUST be persisted to a Polarion custom field so that it can be reviewed, signed off, baselined, and exported.

Persisting Calculated Values

Calculated column values are written to the underlying Polarion field when:
  • A user edits any field in the row within Risksheet, which triggers a save that includes formula results
  • A bulk recalculation is performed across the document — this evaluates all formula columns and writes the results to their bound Polarion fields in a single operation. Use this after importing rows from outside Risksheet (CSV import, SOAP API, copy from template) or after changing a formula definition so that all stored values reflect the new logic.
  • The data sync feature (introduced in version 24.5.1) explicitly stores formula column values to Polarion
If you import work items into Polarion (e.g., via CSV import or API) without editing them in Risksheet, the calculated column values will appear empty in Excel exports. This occurs because the formula values exist only in the browser during the Risksheet session but have not been written to the underlying Polarion fields. Run bulk recalculation to populate the stored values before export.

Comparing Revisions

Because calculated values are persisted as standard Polarion fields, you can use the compare feature to inspect how a formula’s stored result changed between two revisions of the document. This is useful for change-control reviews — you can see, for example, that an RPN went from 240 (yellow) at the previous baseline to 96 (green) after a mitigation was added, with both numbers backed by the corresponding stored field values.

Export Behavior by Format

Row Header Styling with Formula Values

The row header renderer can also reference formula column values. For example, the rowHeaderRpnNew renderer accesses info.item['rpnNew'] to color row headers based on the revised RPN:
When using enum or rating field values in row header styling, access the value using info.item['fieldId'] and compare against the option IDs (not display names). Ratings are defined as Polarion enumerations (Administration -> Enumerations) and bound to risk work item fields; their option IDs are typically integers for severity/occurrence/detection scales.

Limitations and Edge Cases

Dependent Enums Not Driven by Formulas

Dependent enum dropdowns (where child enum options filter based on a parent enum selection) are a column-level feature (v25.3.1+) for enum/multiEnum columns. They cannot be driven by a formula — a formula column produces a single computed value, not a filtered option set.

Ratings Use Integer IDs

Rating scales are defined as Polarion enumerations and bound to risk work item fields. Their option IDs are typically integers. When writing formulas that reference rating values, info.item['fieldId'] returns the integer option ID of the selected rating, which can be used directly in arithmetic (e.g., multiplying severity, occurrence, and detection ratings to compute RPN).

Formula-Calculated Dropdowns Not Available

Creating a dropdown column whose options are determined by a formula is not currently supported. Dropdown columns must reference Polarion enumerations via type: enum:<enumId>, type: multiEnum:<enumId>, or type: rating:<enumId>. Formula columns produce computed scalar values only — they cannot generate dynamic option lists.

Drag and Drop Not Supported

Inserting existing work items into a Risksheet via drag and drop is not supported. Work items must be created through the grid’s “New” menu or linked via item link columns. This is relevant for calculated columns because items created outside Risksheet may not have formula values persisted until they are edited within the grid or bulk-recalculated.

Configuration Interaction Summary

Complete Example

A complete FMEA risk analysis configuration with initial and revised RPN calculated columns, conditional formatting, and row header coloring:
Last modified on July 10, 2026