Architecture

This page builds a mental model of how Risksheet fits into Siemens Polarion ALM, how data flows between the grid and the platform, and where the boundaries of the product lie. If you understand this picture, the rest of the documentation — configuration, traceability, review workflows, export — will fit together naturally.

​

The Core Idea: A View Onto Polarion

A useful analogy: think of Risksheet the way you would think of a spreadsheet view over a relational database. The spreadsheet is a workspace for analysis — sorting, filtering, formulas, conditional formatting — but the rows are records in the database. Closing the spreadsheet does not delete the records, and opening a different spreadsheet over the same table shows the same data, possibly arranged differently. In our case, the “database” is Polarion’s work-item store, and the “spreadsheet” is the risksheet grid embedded in a Polarion LiveDoc. Risksheet adds three things on top of Polarion:

1. A grid renderer that turns work items into rows and fields into columns, with cell merging, calculated values, conditional formatting, and saved views.
2. A sheet configuration that declares the structure of that grid — which columns to show, how to group rows visually, how to calculate values, how to style cells.
3. A small server-side component that loads the configuration, mediates communication between the browser grid and Polarion’s work-item APIs, and handles export.

That is the entire product surface. There is no Risksheet database, no Risksheet user directory, no Risksheet permission system.

​

The Two Halves: Browser Grid and Server Extension

Risksheet has two cooperating parts:

• Client-side grid — JavaScript code that runs in the user’s browser inside the Polarion LiveDoc page. It renders rows, evaluates JavaScript formulas, applies cell decorators, handles editing, and drives the review UI.
• Server-side extension — a Polarion plugin that exposes endpoints for the grid to load configurations, fetch work-item data, save edits in batches, and generate PDF and Excel exports.

This split has practical consequences:

• Formulas and conditional formatting are JavaScript that runs in the browser. They can react instantly to user input without a server round-trip, but they can only see data Polarion has already loaded into the page.
• Edits are saved through the server extension, which writes work items via Polarion’s own APIs. Risksheet does not bypass workflow, signatures, or field-level permissions — if Polarion would have rejected a write, Risksheet’s save will fail in exactly the same way.
• The grid behaves the same regardless of how the user reached it (LiveDoc page, direct link, embedded view). The configuration is attached to the document, not to a session.

​

What a Risksheet Actually Contains

When you open a risksheet, three layered ingredients combine: Risksheet keeps these three concerns separate on purpose. The work items are the audited record. The sheet configuration is a declarative description of how to show those records. Custom logic — risk matrices, complex conditional rendering, branded PDF layouts — lives in separate Velocity templates so that changes to it do not perturb the declarative configuration. This separation matters in regulated industries (ISO 26262, ISO 14971, IEC 61508, ISO/SAE 21434), where the scope of validation is smaller when configuration and custom code change independently. For details about how the configuration is loaded and inherited, see Configuration Hierarchy.

​

The Risk Item as Aggregation Point

Looking at a risksheet from a methodology angle (FMEA — Failure Mode and Effects Analysis, HARA — Hazard Analysis and Risk Assessment, TARA — Threat Analysis and Risk Assessment, STRIDE, CVSS — Common Vulnerability Scoring System), the central object is the risk item — a single Polarion work item that ties together everything an analyst needs to assess one failure mode, hazard, threat, or vulnerability. The risk item is best understood as a mapping table: A single row in the grid maps:

• Context — the function, system item, hazard, or scenario the risk applies to (typically a linked upstream work item)
• through risk attributes — the failure mode, cause, effect, or threat description
• to a classification — numeric or categorical scoring (severity, occurrence, detection, ASIL — Automotive Safety Integrity Level, RPN — Risk Priority Number, CVSS score)
• with mitigations — linked downstream tasks, safety requirements, or controls
• to a residual risk — the reassessed scoring after mitigations are applied.

All of these are fields or link roles on the same Polarion work item, surfaced as columns in the grid. Reading the row left to right traces the analytical chain from “what could go wrong” through “what we did about it” to “what risk remains”. This shape is the same whether the methodology is FMEA, HARA, TARA, STRIDE, or CVSS — only the column names, scales, and standards change. Risksheet is a generic tool that supports any of these methodologies; Nextedy provides solution templates for typical methodologies across industries. For the underlying work-item structure and the two-entity data model (risk items plus linked task items), see Data Model and Work Items.

​

Data Flow at a Glance

In one sentence: the server loads the configuration and the work items, the browser renders the grid and evaluates formulas, and edits travel back through the server, where Polarion enforces its normal rules before persisting them. A few properties follow directly from this flow:

• No separate cache or shadow store. What you see in the grid is the result of a fresh query against Polarion’s work-item store, scoped to the document and the current view.
• All edits go through Polarion. Workflow transitions, field validations, custom-field constraints, permissions, signatures, and history are all applied by Polarion on save. Risksheet does not have a back door.

​

Security: Polarion Is the Source of Truth

Every row in a risksheet is a Polarion work item, so Polarion — not Risksheet — decides who may read or change it. Risksheet adds no identity system, no parallel permission store, and no external network exposure: it runs inside Polarion’s web container and is reachable only through an authenticated Polarion session. Security is a shared responsibility between the platform and the product. Handled by Polarion — user authentication and authorization (roles, permissions, project access), session management, HTTPS/TLS, Content Security Policy, CSRF protection on state-changing operations, network and OS/JVM/database hardening, central logging, secure secrets storage through the User Account Vault, and the SQL/Lucene query restrictions that are on by default since Polarion 2410. Risksheet relies on these and never bypasses or replaces them. Handled by Risksheet — correct use of the Polarion APIs under the authenticated user’s context, safe rendering of user-controlled data, conservative default limits on how much data a sheet processes and renders, and keeping day-to-day grid work clearly separated from privileged configuration. For the data and permission concerns, that split lands entirely on the platform side: Risksheet does not add a parallel permission system. If a user cannot edit a particular field in Polarion’s own form view, they cannot edit it in the risksheet either — the server rejects the save the same way. If a user cannot read a work item, that work item does not appear in their grid. Administrative actions (changing the sheet configuration, managing licensing, registering documents as risksheets) are gated on Polarion administrative roles.

​

Configuration Is Privileged

Sheet configuration is not user data. It can define formulas, custom cell renderers, and server-rendered templates, so it is treated as privileged — closer to administrative code than to a preference.

• Storage — configuration lives as a document attachment on the LiveDoc (see What a Risksheet Actually Contains), which means it is governed by Polarion’s standard document and attachment permissions rather than by a separate Risksheet access layer.
• Management — the configuration editor is restricted to users with at least Project Administrator privileges.
• Templates — configuration is normally defined once on a template document that many instance documents reference through their templateDoc field.

Because configuration is stored as document data, permissions on template documents and their attachments are part of your security posture. If regular users can edit a template document or its configuration attachment through ordinary Polarion mechanisms, they can change how every risksheet that follows that template behaves — without ever opening the configuration editor.

​

Safe Rendering

Administrator-configured rendering — custom cell renderers, row-header decorators, server-rendered columns, and top-panel templates — controls how work item data is displayed, and its safety depends on which Polarion API the configuration uses:

• Rendering API (for example $item.fields().description().render()) applies Polarion’s built-in HTML sanitization and is the right choice for anything administrator-configurable.
• Open API / raw access — the field value without .render() — returns unsanitized content. Where a template uses it, the administrator is responsible for escaping the output before it reaches the page.

Template scripting is restricted to trusted roles and is not sandboxed beyond that role restriction.

​

Query and Processing Limits

Risksheet applies configurable limits to how much data a single sheet loads and renders, with deliberately conservative defaults (the link suggester’s nextedy.risksheet.suggester.resultLimit, for example, defaults to 20). Raising a limit can affect Polarion’s performance noticeably, so evaluate the change outside production first. For day-to-day expectations about who can do what, see User Roles and Permissions and Data Model and Work Items (which covers work item visibility and levels). For the cross-product picture — the full shared responsibility model, secure development practices, and the administrator checklist — see Product Security.

​

Traceability Without Replication

Risk analysis only matters if it connects to the rest of the engineering record: requirements, hazards, and design elements upstream; mitigations, controls, and tests downstream. Because Risksheet’s rows are real work items, traceability is implemented with Polarion’s own link roles — not by copying data into the grid or maintaining a parallel reference table.

• Upstream context (functions, hazards, requirements) is loaded through link roles defined in the sheet configuration. The values shown in upstream columns are read from the linked items in real time.
• Downstream mitigations (safety requirements, controls, tests) are also linked work items, optionally created inline from the grid. Their fields can be edited through the same grid if the configuration allows.
• Cross-project links are supported wherever Polarion supports them, so shared libraries (a harms catalog, a function catalog, a requirements library) can be referenced from many risksheets without duplication.

This means an existing change-impact analysis in Polarion still works: if you trace a requirement, the risksheets that reference it appear naturally as linked work items. See Traceability and Linking for the link patterns and the configuration options that drive them.

​

Misconceptions Worth Naming

• “Risksheet has its own database.” It does not. The grid is a presentation of Polarion work items.
• “Risksheet is only for FMEA.” Risksheet is a generic risk-analysis grid that supports FMEA, HARA, TARA, STRIDE, CVSS, and other methodologies. Nextedy provides solution templates for typical methodologies across industries; the engine itself is methodology-agnostic.
• “Configuration changes affect all risksheets.” The sheet configuration is attached per document, with inheritance from templates. See Configuration Hierarchy for the resolution order.
• “Approval reviews lock a document.” Risksheet’s approval review records approval-tagged comments — it does not by itself drive Polarion’s formal document workflow states (draft to reviewed to approved). When formal state transitions are required, they remain a Polarion document-workflow action. See Review Workflows for the three review styles and their boundaries.

​

Where to Go Next

• For a higher-level positioning of the product, read What is Risksheet?.
• For the data shape behind the grid, read Data Model and Work Items.
• To put the model to work, see the How-To Guides, in particular Risk Management and Configuration Management.