Why Configuration Hierarchy Matters
Think of RISKSHEET configuration like a company’s dress code policy: there’s a company-wide default, department-specific variations, and individual employees might have special accommodations. Similarly, RISKSHEET allows:- Global defaults that apply to all projects
- Project-level overrides that customize behavior for specific projects
- Template-based configurations that define reusable document structures
- Document-specific overrides that allow one-off customizations without affecting the template
The Three Configuration Layers
Layer 1: Project/Global Configuration Properties
These settings are defined in Administration > Configuration Properties and control system-wide behavior that affects how RISKSHEET interacts with Polarion. Examples include:nextedy.risksheet.branchingSupport- Enables support for branched documentsnextedy.risksheet.checkInstanceFieldPermissions- Controls field-level permission checksnextedy.risksheet.upstreamSubColumnsReadonly- Determines if upstream columns are editable
Layer 2: Template-Level Configuration
The template configuration is stored as arisksheet.json file attached to a template document. This is the primary location for defining:
- Column structure (headers, bindings, types)
- Formulas and calculated fields
- Cell styling and conditional formatting
- Data types (risk, task, review)
- Hierarchical levels
risksheet.json, all documents pointing to that template receive the updates—unless they have document-specific overrides.
Layer 3: Document-Specific Configuration
When you attachrisksheet.json directly to a RISKSHEET document (not the template), that configuration takes precedence over the template. This creates a detached configuration that:
- No longer receives updates from the template
- Allows document-specific customization
- Requires manual synchronization if template changes are needed
Configuration Resolution Process
When RISKSHEET loads a document, it searches for configuration in this order:RISKSHEET ships with a built-in default configuration that provides basic FMEA columns and structure. This serves as a fallback when no custom configuration is found.
Template Override: Switching Between Layers
The Menu > Configuration > Override Template action is the key mechanism for moving between template-based and document-specific configuration.What “Override Template” Does
- Copies the current template’s
risksheet.jsonto the document as an attachment - Severs the link to the template—future template changes will not propagate to this document
- Allows editing this document’s configuration independently
Common Use Cases
| Scenario | Recommended Approach |
|---|---|
| Need consistent configuration across 50+ risk documents | Use template-based configuration (Layer 2) |
| One document needs an extra column not in the template | Use Override Template, then edit document config (Layer 3) |
| Testing a new formula before rolling it out organization-wide | Create a test document, Override Template, experiment in Layer 3 |
| Need to exclude one document from global template updates | Use Override Template to detach it |
Property-Level Precedence
Within therisksheet.json file itself, some properties can exist at multiple levels:
global.*properties (culture, help, refreshOnSave) apply document-widecolumns[].readOnlycan be overridden by permission checks (Layer 1)dataTypes.*.typecan use Velocity expressions evaluated against global properties
Multi-Project Scenarios
In organizations with multiple Polarion projects, configuration hierarchy becomes more complex:- Project-level properties are scoped to a single project
- Global properties (defined at the repository level) apply to all projects
- Templates can be shared across projects via cross-project document references
Configuration Editor and Hierarchy
Starting with version 25.5.0, the configuration editor (Menu > Configuration > Edit Risksheet Configuration) provides:- Visual indication of whether you’re editing template or document-specific configuration
- Template override wizard that walks through the detachment process
- Configuration history showing which layer each property comes from
- Download support for backing up configurations before making changes
Common Pitfalls
Misconception 1: “Attaching risksheet.json makes it a template”
Reality: Attachingrisksheet.json to a document makes it a configuration source, but other documents only inherit from it if their templateDoc field points to that document.
Misconception 2: “I can revert document-specific config to template-based”
Reality: Override Template is a one-way operation. To revert, you must manually delete the document-attached file and clear cached configuration.Misconception 3: “Global properties always override document config”
Reality: Global properties (Layer 1) control system behavior, while document config (Layer 2/3) controls structure. They operate in different domains—global properties affect how RISKSHEET interprets document config, not what that config contains.Related Topics
- Configuration System - Overview of the property-based configuration architecture
- Use the Configuration Editor - Step-by-step guide to editing configurations
- Override Template Configuration - How to detach a document from its template
- Set Up Global Templates - Creating reusable templates for multiple documents
- Configure Template Paths - Defining where templates are stored
- Risksheet.json Format - Complete reference for configuration file structure
Sources
Sources
KB Articles
- Adjusting Risksheet configuration
- Risksheet Configuration Properties
- Setup risk review process
- Configure Multiple Risk Item types
RisksheetViewServlet.javaRisksheetProjectProperties.javaAppConfigParser.tsAppConfig.tsPolarionAppConfigManager.java