> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # Basic Configuration > By the end of this tutorial you will understand how Nextedy RISKSHEET is configured, recognise the three configuration files involved, locate the sheet configuration on a Polarion LiveDoc, and make a small, safe change using the built-in YAML configuration editor. You will leave with a mental model of what belongs in each file and where to go next for deeper customization. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; ## What you will achieve By the end of this tutorial you will understand how Risksheet is configured, recognise the three configuration files involved, locate the sheet configuration on a Polarion LiveDoc, and make a small, safe change using the built-in YAML configuration editor. You will leave with a mental model of what belongs in each file and where to go next for deeper customization. ## Prerequisites * Risksheet is installed on your Siemens Polarion ALM instance (see [Installation](/risksheet/getting-started/installation)) * You are familiar with the grid and toolbar (see [Understanding the Interface](/risksheet/getting-started/understanding-interface)) * You have administrator permissions on the Polarion project Risksheet is a flexible tool. It supports any risk-management methodology, including Failure Mode and Effects Analysis (FMEA), Hazard Analysis and Risk Assessment (HARA), Threat Analysis and Risk Assessment (TARA), STRIDE, and Common Vulnerability Scoring System (CVSS). Nextedy ships solution templates for typical methodologies across automotive, medical, aerospace, and cybersecurity. Always pick the closest template and adapt it -- do not build a configuration from an empty file. ## The three configuration files A risksheet is shaped by three distinct configuration files. Each lives as an attachment on the Polarion LiveDoc (or on a template document) and each addresses a different concern. | File | Purpose | Format | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------ | | Sheet configuration (`risksheet.json`) | Declarative grid definition: columns, hierarchical levels, data types, formulas, styles, cell decorators, views, reviews | JSON, edited as YAML in the configuration editor | | Top panel configuration (`risksheetTopPanel.vm`) | Velocity template for the information panel above the grid; hosts custom UI controls and shared JavaScript helpers | Velocity | | PDF export configuration (`risksheetPdfExport.vm`) | Velocity template that controls the layout and styling of PDF exports | Velocity | This separation matters for regulated industries (ISO 26262 automotive, ISO 14971 medical, IEC 61508 industrial, ISO/SAE 21434 cybersecurity). The sheet configuration is a declarative, auditable artifact that describes both WHAT the grid shows and HOW its values are calculated and styled: formulas, conditional formatting (cell decorators), and styles all live in the sheet configuration. The top panel template covers only the content of the information panel above the grid, and export presentation lives in its own template. Each layer can be reviewed, validated, and changed independently. diagram ## Where the configuration lives -- Polarion vs. Risksheet A common point of confusion is what is configured in Polarion itself and what is configured in the sheet configuration. The boundary is simple: | In Polarion administration | In the sheet configuration | | ------------------------------------------------------------------------------ | -------------------------------------------------------------- | | Work item types (for example a "Failure Mode" or "Hazard" type) | Which work item type the grid uses for risk items and tasks | | Custom fields on those work item types | Which fields the columns are bound to | | Enumerations (severity scales, occurrence scales, classification, ASIL levels) | How those enumerations are displayed and styled | | Link roles between work items | Which link role connects a risk item to its related work items | | Document type (so a LiveDoc behaves as a risksheet) | The grid layout that the document presents | Severity, occurrence, detection scales and any other rating dropdown live in **Administration > Enumerations** in Polarion. A custom field on the work item is bound to one of these enumerations. The sheet configuration then references the field through a column entry, and the server loads the enum values automatically. Risksheet does not have its own database. Every value you enter in the grid is a Polarion work item field. Permissions, versioning, audit history, and traceability are all provided by Polarion. Risksheet is the visual surface that organises and edits this data. 1. Open your risksheet document in Polarion. 2. From the toolbar, choose **Menu > Configuration > Edit Risksheet Configuration**. 3. The configuration editor opens in a new browser tab. You should see the YAML editor on the left and a preview/validation pane on the right. The editor (available since v25.5.0) offers syntax highlighting, inline error detection, and edit history. The underlying attachment is JSON, but you should always edit it as YAML through this editor. YAML is easier to read, easier to diff, and harder to break. Treat raw JSON edits as a last-resort fallback. Scroll through the YAML. A real, working sheet configuration is made up of these top-level sections: | Section | What it controls | | ---------------- | ------------------------------------------------------------------------------------ | | `global` | Culture/locale, toolbar settings, refresh behaviour | | `columns` | Every column shown in the grid -- the core of the configuration | | `levels` | The visual hierarchy created by cell merging (for example item, failure mode, cause) | | `dataTypes` | Which Polarion work item types are used for risk items and tasks | | `formulas` | Named JavaScript functions that calculate values such as Risk Priority Number (RPN) | | `styles` | Named CSS classes used by cell decorators | | `cellDecorators` | Logic that applies styles to cells based on their value | | `headers` | Row and column header sizing | | `reviews` | Review workflow integration | | `sortBy` | Default sort order | | `views` | Saved column-visibility presets (optional) | | `queryFactories` | Advanced autocomplete filtering (rare) | A section the engine does not recognise is simply ignored. (Beyond the core sections above, a few optional root-level keys also exist -- such as a root `readonly` flag -- and the server injects read-only runtime fields, described in [What to leave alone](#what-to-leave-alone) below.) If you came across older guides mentioning a top-level `ratings`, `enums`, or `relations` block, treat them as outdated: rating scales and enumerations live in Polarion, not in the sheet configuration. The `dataTypes` section names the two Polarion work item types the risksheet operates on. Locate it and confirm both entries look broadly like this: ```yaml theme={null} dataTypes: risk: type: failureMode task: name: Task type: mitigationAction role: mitigates zoomColumn: taskId ``` The `risk` entry is the main row work item; the `task` entry is the downstream linked item (mitigations, safety requirements, controls). The `name` shown in the toolbar, the link `role`, and the `zoomColumn` used for navigation should all reflect your project's vocabulary. `risk` and `task` are just keys. The underlying work item types can be anything in your project -- requirements and test cases, hazards and controls, threats and countermeasures. Risksheet works as a generic two-entity traceability grid. A good first edit is renaming a column header. Find a column in the `columns` list and change only its `header` text: ```yaml theme={null} columns: - id: severity bindings: severityField header: Severity (S) type: rating:severityEnum level: 2 ``` Save. The configuration editor validates the YAML. If validation passes, return to the risksheet document and use the Refresh button in the risksheet toolbar (or reload the document) -- the new header appears in the grid. The column property that maps to a Polarion field is `bindings` (plural). A singular `binding` is silently ignored, leaving the column blank. Highlighting RPN cells in green, amber, or red is a three-part collaboration inside the sheet configuration: 1. A **formula** computes a value (for example RPN = severity x occurrence x detection). 2. A **cell decorator** inspects the value and toggles a CSS class on the cell. 3. A **style** defines what that CSS class looks like. A minimal example: ```yaml theme={null} formulas: rpn: (info) => { return info.item.severity * info.item.occurrence * info.item.detection; } cellDecorators: rpn: | (info) => { var v = info.value; $(info.cell).toggleClass('rpn1', v <= 150); $(info.cell).toggleClass('rpn2', v > 150 && v <= 250); $(info.cell).toggleClass('rpn3', v > 250); } styles: .rpn1: '{background-color: #eaf5e9 !important; color: #1d5f20 !important;}' .rpn2: '{background-color: #fff8e1 !important; color: #8a6d00 !important;}' .rpn3: '{background-color: #fdecea !important; color: #b71c1c !important;}' ``` | RPN range | Style class | Meaning | | ------------- | ----------- | ----------------------------------- | | 0 -- 150 | `rpn1` | Acceptable risk | | 151 -- 250 | `rpn2` | Reduce as reasonably practicable | | 251 and above | `rpn3` | Unacceptable -- mitigation required | These thresholds are deployment-specific. Adjust them to match the risk acceptance criteria of your project or standard. Style values must be wrapped in `{ ... }` braces, as shown above. Without the braces the engine cannot parse them and the cell remains unstyled. ## What to leave alone A few properties you may see in real configurations are managed by the server at runtime. Do not set them by hand -- they are informational only: * `canAdmin` -- whether the current user has admin rights * `reviewer` -- whether the current user is in reviewer mode * `source` -- path to the configuration source (document or template) * `templateName` -- name of the template the configuration was loaded from ## Next steps * Tour each section of the sheet configuration in [Configuration Reference](/risksheet/reference/configuration/index) * Learn about column types and calculations in [Column Types](/risksheet/reference/columns/index) and [Formulas](/risksheet/reference/formulas/index) * Apply visual hierarchy through cell merging in [Risk Management Guides](/risksheet/guides/risk-management/index) * Customise styling for risk levels in [Styling and Formatting](/risksheet/guides/styling/index) * Build saved column presets for staged workflows in [Configuration Management](/risksheet/guides/configuration/index) * Manage templates and inheritance in [Templates](/risksheet/reference/templates/index) * See full working examples in [Configuration Examples](/risksheet/reference/examples/index)