Risksheet formulas are JavaScript functions that calculate derived values for grid cells. Each formula receives an info context object and returns the computed value.
Every formula function receives a single info parameter containing the following properties:
Property
Type
Description
info.item
object
The current row’s data object containing all field values, accessed by column binding ID (e.g., info.item['sev'])
info.value
any
The current stored value of the cell being calculated, before the formula runs
info.cell
HTMLElement
The DOM element representing the cell (available during rendering)
Formulas execute during cell rendering. When a formula result differs from the stored value, Risksheet can mark the item as edited. Formula changes respect the readOnly column setting. This means formulas only run when their column is visible in the current view.
Formulas are declared as named entries in the top-level formulas object of risksheet.json. Each entry is a JavaScript function written as a string value:
Name of the formula defined in the formulas object. When set, the column becomes read-only by default
readOnly
boolean
false
Automatically set to true when formula is specified. Can be explicitly set to false to allow manual overrides of formula values
binding
string
Column id
The data field the formula writes its result to. Also used in info.item[binding] to read values from other columns
type
string
Auto-detected
Data type of the column. Formula columns can output any supported type (int, float, string, etc.)
cellDecorator
string
None
Name of a cell decorator function to apply visual styling based on the formula’s computed value
When formula is set on a column, Risksheet automatically makes the column read-only. If you set readOnly: false on a formula column, changes made outside Risksheet may drift from formula-calculated values. Use Menu > Rows > Check stored formulas to reconcile stored values with recalculated formula output (available since v24.5.1).
The standard Risk Priority Number formula multiplies severity, occurrence, and detection ratings. This is the most common formula in FMEA configurations:
{ "formulas": { "commonRpn": "function(info){ var value = info.item['occ']*info.item['det']*info.item['sev']; return value?value:null;}" }}
Parameter
Source Binding
Description
Severity
info.item['sev']
Severity rating value from the sev column
Occurrence
info.item['occ']
Occurrence rating value from the occ column
Detection
info.item['det']
Detection rating value from the det column
Return behavior: Returns the product of all three values. If any value is falsy (zero, null, or undefined), returns null to avoid displaying zero for incomplete rows.
Available since v24.9.1The risksheet.ds.getMasterRowsByColumnValue() function enables cross-row data aggregation. This is critical for FMEA workflows where parent process step rows need to summarize characteristics from child risk items.
columnId: binding ID of the column to match; value: the value to filter by
Array of row data objects where the specified column matches the given value
Use case: Aggregate unique enum values from downstream risk itemsIn a process FMEA, the parent process step may need to collect all unique process characteristics from its child risk items:
{ "formulas": { "aggregateUnique": "function(info){ var rows = risksheet.ds.getMasterRowsByColumnValue('parentId', info.item['parentId']); var values = []; for(var i=0; i<rows.length; i++){ var v = rows[i]['characteristic']; if(v && values.indexOf(v)===-1) values.push(v); } return values.join(', '); }" }}
Expanded for readability:
function(info) { var rows = risksheet.ds.getMasterRowsByColumnValue( 'parentId', info.item['parentId'] ); var values = []; for (var i = 0; i < rows.length; i++) { var v = rows[i]['characteristic']; if (v && values.indexOf(v) === -1) { values.push(v); } } return values.join(', ');}
Use case: Sum numeric values across child items
function(info) { var rows = risksheet.ds.getMasterRowsByColumnValue( 'parentId', info.item['parentId'] ); var total = 0; for (var i = 0; i < rows.length; i++) { total += rows[i]['riskScore'] || 0; } return total > 0 ? total : null;}
Use the summation pattern for rolling up numeric risk scores or counts. Use the unique-value pattern for collecting distinct enum values (e.g., process characteristics, risk categories) from multiple child risk items into a parent row.
Automatically construct a title from component fields:
{ "formulas": { "autoTitle": "function(info){ var h = info.item['hazard']||''; var e = info.item['effect']||''; return h && e ? h+' - '+e : null; }" }}
function(info) { var status = info.item['riskStatus']; if (status === 'mitigated') return 'Complete'; if (status === 'open') return 'Action Required'; return 'Pending';}
Formula comparisons must use enum IDs (e.g., 'mitigated'), not display values (e.g., 'Mitigated'). The enum type identifier in risksheet.json must match the definition in Polarion’s XML custom field file. Check your .polarion/documents/fields/custom-fields.xml for the correct ID values.
For complex calculations that exceed inline formula capacity, define functions in the risksheetTopPanel.vm file and call them from formulas. This pattern is also the only way to access document-level custom fields or external data sources.
Document-level custom fields are not directly available in risksheet.json formulas. Access them via $doc.getOldApi().getValue('customFieldID') in the risksheetTopPanel.vm Velocity script section, then bridge the values into your formulas through global JavaScript functions:
#set($myField = $doc.getOldApi().getValue('customFieldID'))<script> var docCustomValue = '$myField'; function getDocField(info) { return docCustomValue; }</script>
The risksheetTopPanel.vm can reference external data sources via Velocity context and Polarion APIs (e.g., reading risk acceptance matrix values from an XML configuration file). This enables dynamic risk matrix definitions shared across projects without duplicating formula logic in each risksheet.json.
Work item data can be accessed in top panel functions via info.item['fieldId']. Prepare all needed values within functions defined in the top panel file, then return the result to risksheet.json formulas:
// risksheetTopPanel.vmfunction computeComplexResult(info) { var val1 = info.item['customField1']; var val2 = info.item['customField2']; // Complex calculation logic here return val1 + val2;}
Formulas compute the value; cell decorators apply visual styling based on that value. The two work together but are configured separately in risksheet.json.The cellDecorators entry for RPN values applies CSS classes based on risk thresholds:
{ "cellDecorators": { "rpn": "function(info){ var val = info.value; $(info.cell).toggleClass('boldCol', true ); $(info.cell).toggleClass('rpn1', val>0 && val <= 150 ); $(info.cell).toggleClass('rpn2', val > 150 && val <= 350); $(info.cell).toggleClass('rpn3', val > 350);}" }}
Formulas execute during cell rendering, which means a formula only runs when its column is visible in the current view.
If a formula column is hidden (not visible in the current saved view), its formula does not execute. If other formulas or cell decorators depend on the hidden column’s value, they will read a stale or null value. Use Saved Views for export-specific layouts, but never set an export-only view as the default view since formulas run on sheet load.
Available since v24.5.1When formula columns have readOnly: false, or when items are edited outside Risksheet (for example, through Polarion’s standard work item editor), stored values may drift from formula-calculated results. To reconcile:
Open the Risksheet document
Navigate to Menu > Rows > Check stored formulas
Risksheet recalculates all formula columns and flags any differences
Formula-generated fields may trigger save failures when permissions restrict editing. If stored values differ from formula output (e.g., after data migration where titles were truncated), Risksheet tries to save the recalculated values, which are then blocked by permissions. Verify stored values match formula output before enabling strict permission enforcement.
This configuration creates two RPN columns (initial and revised), each with color-coded risk thresholds applied via cell decorators. The row header uses the revised RPN color for at-a-glance residual risk assessment.