Configure Variant Management - Nextedy Documentation

Prerequisites

Branching support enabled in your Polarion environment
Polarion administrator access for custom field configuration
Familiarity with Polarion document branching and release management

How Variant Management Works

Risksheet supports variant management through branched documents combined with release-based filtering. A base project contains the master risk analysis, while variant projects branch from it for specific product releases. Each variant filters downstream items by an assignedReleases document custom field, showing only the mitigation tasks and controls relevant to that release.

Step 1: Enable Branching Support

Variant management builds on Risksheet’s branching capabilities. Ensure the branching property is set in your Polarion system configuration:

nextedy.risksheet.branchingSupport=true

Use lowercase n in nextedy.risksheet.branchingSupport. An uppercase N will silently fail and branching features will not appear.

Step 2: Set Up the Release Custom Field

Create a document-level custom field to track which product release each risk document belongs to:

Navigate to Administration > Document Configuration > Custom Fields
Create a custom field named assignedReleases of type multiEnum
Define your release values (e.g., v1.0, v2.0, v3.0)
Apply the field to your risk analysis document types

The assignedReleases field is used to filter downstream items by release version. Verify the exact field name and type supported in your Polarion environment.

Step 3: Create a Variant Project Structure

For complex variant management, set up a dedicated project structure:

Keep your base project with the master risk analysis documents
Create variant projects by branching the base project for each release
Assign the appropriate release value to each branched document using the assignedReleases field

Risksheet supports multiple different configurations within a single project. Each document can have its own risksheet.json attached, so variant documents can use different column layouts, formulas, or filtering rules than the base project documents. No mandatory fields or work item types are required — the tool is fully configurable.

Step 4: Configure Release-Based Filtering

In the variant project’s Risksheet configuration, set up downstream item filtering based on the assigned release. The assignedReleases document custom field controls which downstream items appear in the Risksheet view for each release.

The release filtering currently supports assigning one release value per document. Assigning multiple releases to a single document does not yet enable per-release filtering within the Risksheet view. As a workaround, create separate documents for each release.

Step 5: Scope Items to Documents

Use the document property in your dataTypes configuration to restrict linked items to specific LiveDocs, preventing the Risksheet from showing mitigation tasks from other documents or releases:

{
  "dataTypes": {
    "task": {
      "type": "measure",
      "role": "has_measure",
      "document": "Risks/FMEA Measures"
    }
  }
}

You can also use createInCurrentDocument to control whether new upstream items are stored in the current document rather than a shared location. This keeps variant-specific items scoped to the correct release context.

Step 6: Handle Overwritten Items in Variants

When working with branched variant documents, you may need to modify items originally inherited from the base project:

Right-click the referenced item in the Risksheet grid
Select Overwrite Row Item from the context menu
The item changes from reference type to overwrite, becoming a local editable copy

The overwrite functionality is only available when the item’s systemReferenceType is reference. After overwriting, the item can be edited independently of the base project version.

Overwriting upstream work items in branched documents removes all existing links except the “is branched from” relationship. Plan for this by:

Documenting link structures before overwriting
Using custom scripts to restore backlinks after the overwrite
Clearing the Polarion cache after branching operations to ensure fresh data

Known Limitations

Limitation	Workaround
Multi-release document filtering not available	Assign one release per document, or use separate LiveDocs
Overwriting removes all links except “is branched from”	Custom script to restore backlinks
Release field currently hardcoded to multiEnum	Assign only one release per document
Cache may become stale after branching	Clear Polarion cache after branching operations

Verification

After setting up variant management:

Open a branched variant document in Risksheet
You should now see only downstream items filtered by the assigned release
Referenced items from the base project should display as read-only
Overwriting an item should create a local editable copy in the variant
Verify that new items created in the variant are scoped to the correct document

​Prerequisites

​How Variant Management Works

​Step 1: Enable Branching Support

​Step 2: Set Up the Release Custom Field

​Step 3: Create a Variant Project Structure

​Step 4: Configure Release-Based Filtering

​Step 5: Scope Items to Documents

​Step 6: Handle Overwritten Items in Variants

​Known Limitations

​Verification

​See Also

Prerequisites

How Variant Management Works

Step 1: Enable Branching Support

Step 2: Set Up the Release Custom Field

Step 3: Create a Variant Project Structure

Step 4: Configure Release-Based Filtering

Step 5: Scope Items to Documents

Step 6: Handle Overwritten Items in Variants

Known Limitations

Verification

See Also