Risksheet does not maintain its own data store. Risk items, task items, links, and field values all live in Polarion work items, subject to Polarion authorization and Polarion’s full audit history. Risksheet visualizes and edits that data — it does not duplicate it.
Calculated Values Are Polarion Data
The grid is dense with calculated values: a Risk Priority Number (RPN) built from severity, occurrence, and detection; an Automotive Safety Integrity Level (ASIL) derived from severity, exposure, and controllability; a recommended action category derived from a risk matrix. In a spreadsheet, these would be ephemeral cell formulas. In Risksheet, they have a second life: they are persisted as real values on real Polarion work items. That dual nature — calculated in the browser, stored on the server — is what makes Risksheet auditable. A regulator or quality auditor browsing the Polarion work item one year from now will see the same RPN that the engineer saw on the day the risk was assessed, even if formula coefficients or rating scales have since been adjusted.The “live” vs “stored” pair
A useful mental model is to think of every calculated cell as having two values living together:- A live value — what the formula evaluates to right now, given the current inputs in the row and the formula function in the current sheet configuration.
- A stored value — what was persisted to the Polarion work item field the last time the row was saved.
Why the stored value matters
If Risksheet only computed RPNs at view time, three things would break in regulated contexts:- Audit immutability. Reviewers need to see exactly what the original assessor saw. If the formula changes later, recomputing on-the-fly would silently rewrite history.
- External tools. Other Polarion artifacts — LiveReports, Velocity templates, dashboards, exports, and the reporting layer — read directly from Polarion fields. They cannot run Risksheet’s JavaScript formulas. They need a number in the field.
- Filtering and querying. Polarion’s Lucene queries operate on stored field values. To filter “all hazards with RPN > 250” you need 250 to be persisted, not recalculated per request.
When Live and Stored Values Diverge
Most of the time live and stored values match. Several scenarios cause them to drift apart:- Edits outside Risksheet. A user opens the underlying work item in Polarion’s normal LiveDoc editor or work item form and changes severity. The Risksheet formula has not been re-run on that row.
- Formula changes. A configuration administrator updates the RPN formula — for example to change a weighting coefficient or add a new factor. Existing stored values reflect the old formula; new edits will use the new one.
- Rating scale changes. Severity used to range 1–5; the project decides to switch to 1–10. Old stored numbers are now on a different scale than the live formula expects.
- Bulk imports. Rows are created or updated through a script, an import, or the server API. The formulas have not executed for those rows.
readOnly: falseon a formula column. Formula columns can be configured as editable. When they are, a user can type a value directly into the calculated cell, intentionally overriding the formula.
A column with a
formula reference and readOnly: false lets users override the calculated value with a typed one. This is occasionally useful — for example, in early FMEA workshops where a moderator wants to record a value before the formula inputs exist — but it is the most common source of drift between live and stored values. Treat it as the exception, not the default.Reconciling drift — Check stored formulas
For exactly these situations, Risksheet provides a reconciliation action: Menu > Rows > Check stored formulas. This walks the rows currently visible in the grid, re-evaluates every formula column, and writes the live result back into the stored Polarion field where it differs. This is the only routine bulk-recalculation flow you need to know about. It is safe to run after a formula change, after a bulk import, or any time you suspect a column may have stale values. Because it operates row-by-row through normal save transactions, it produces normal Polarion revisions on the affected work items — the change is fully auditable. For the step-by-step procedure, see Run formula recalculation and the broader Manage formula columns guide.Save behavior and scroll position
When you save a Risksheet, the grid by default refreshes to show the persisted state. On large sheets this can scroll the view back to the top, which is disorienting if you have just added a row near the bottom. Theglobal.refreshOnSave property controls this:
refreshOnSave: true(default) — the grid reloads the saved state. Safer for collaborative editing but causes scroll-to-top.refreshOnSave: false— keeps focus on the last edited cell after save. Recommended for large risk analyses where you make many edits per save cycle.
Comparison Mode — Diffing Assessment Versions
A risk analysis evolves. Severity ratings are re-estimated as new evidence arrives, mitigations are added, classifications change. Auditors and reviewers regularly need to answer the question: what changed since the last review? Risksheet’s comparison mode answers this by diffing the current sheet against a specific past revision of the underlying LiveDoc document.How comparison works
Risksheet versioning rides on top of the underlying LiveDoc document. Every save of the risksheet produces a Polarion document revision in the normal way. Comparison mode loads two snapshots — the current state and a chosen historical revision — and overlays them in a single view, highlighting cells that differ.
What you see in comparison mode
When comparison is active, the grid switches into a read-only diff view with the following definite behaviors:- Mandatory sorting. The grid is sorted by Item ID and then by Revision. This is not optional and not user-configurable while comparison is active. The diff alignment depends on this sort order — disabling it would make pair-matching ambiguous.
- Disabled custom renderers. Columns that normally use a custom
cellRenderer(server-rendered Velocity, custom HTML decorators, attachment renderers) fall back to plain value display in comparison mode. The diff highlighter operates on field values, not on rendered output. - Disabled task column sorting. Task columns cannot be re-sorted while comparison is active. They follow the parent risk item’s order so that linked tasks stay grouped with their parent.
- Cells flagged as changed. Cells whose value differs between the two revisions are visually distinguished. New rows (present in current but not in the historical revision) and removed rows (present in the historical revision but not in current) are marked as well.
Baselining
Comparison works against any revision in the document’s history, but in practice teams use it most against baselines: named milestones in the LiveDoc revision graph corresponding to formal review gates, releases, or audit dates. Because risksheet versioning is the underlying LiveDoc’s versioning, the same baselines you create for the document (Polarion Baselines view) are available as comparison targets in Risksheet. This is the architectural reason “Risksheet versioning” feels so seamless: there is no separate Risksheet revision counter. Saving the document saves the risksheet. Baselining the document baselines the risksheet. Comparing against a baseline compares the risksheet inside that baseline. For practical workflows see Compare risksheet revisions and Manage risksheet baselines.Common Misconceptions
“I changed the formula, so the existing RPNs are now wrong.” The existing stored RPNs are unchanged. The live recalculation only happens on rows you re-touch. Run Menu > Rows > Check stored formulas to bring stored values in line with the new formula. “Risksheet has its own database that gets out of sync with Polarion.” There is no separate database. The “drift” you sometimes see is between client-side recalculation and server-stored fields — both inside Polarion, just at different layers. See Risksheet architecture for the layering picture. “Comparison mode is comparing my unsaved edits against the server.” No. Comparison loads two committed revisions of the LiveDoc — typically the current saved state and a chosen historical revision. Unsaved local edits are not what the diff is showing. “I can’t find a row in my comparison view that I know I edited.” Comparison forces sort by Item ID and Revision. Your edit is there, just in its sorted position — not where it sat in your usual saved view. “The image I exported looks different from the grid.” Some renderings — custom cell renderers, server-rendered Velocity, embedded images — are not preserved identically in Excel and PDF exports. This is unrelated to data sync; the underlying field values are correct.Where to Go Next
- For the layered architecture (browser app, server communication, Polarion API) see Risksheet architecture.
- For the work item model that all this data lives on, see Data model and work items.
- For how cross-project links work, including unlinking and traceability across project boundaries, see Traceability and linking.
- For practical recalculation procedures, see the Risk management guides.
- For configuration of formulas and styles, see the Formulas reference and Cell decorators.