Skip to main content

​
Current Status

Nextedy RISKSHEET does not currently support Polarion Collections as a first-class organizational unit. This means:
  • Risksheet documents cannot be directly scoped to a specific Collection
  • Collection-aware filtering (e.g., showing only work items within a Collection) is not available
  • Collection-based permission inheritance does not apply to Risksheet views
Collections support is planned for future development, with PowerSheet receiving priority implementation. Monitor the Changelog for updates on Collections integration roadmap.

​
Why Collections Matter

Polarion Collections enable teams to:
  • Organize multi-release projects: Group work items, documents, and plans by release version
  • Scope queries and reports: Filter content to a specific product variant or configuration
  • Manage permissions: Apply role-based access control at the Collection level rather than project-wide
diagram Without Collections support, Risksheet views span the entire project regardless of Collection boundaries.

​
Workarounds for Multi-Release Scenarios

Use Polarion’s branching feature to create release-specific Risksheet documents:
  1. Create a baseline for each release (e.g., v1.0-baseline)
  2. Branch your Risksheet document from that baseline
  3. Each branch contains a frozen snapshot of work items from that release
Advantages:
  • True isolation between releases
  • Historical traceability preserved
  • No custom field configuration required
Limitations:
  • Changes to shared work items require manual propagation across branches
  • Branched documents are read-only unless configured with editableReferencedWorkItems
See Work with Branched Documents for complete setup instructions.

​
Option 2: Custom Field Filtering

Create a custom field to tag work items by release or variant, then filter Risksheet queries:
  1. Add a targetRelease multiEnum field to work item types
  2. Configure Risksheet query to filter by release:
{
  "query": "targetRelease:Release_2.0",
  "dataTypes": {
    "risk": {
      "type": "risk",
      "role": "relates_to"
    }
  }
}
Advantages:
  • Single Risksheet document can be filtered dynamically
  • No branching overhead
  • Easier to maintain shared work items
Limitations:
  • Requires manual tagging of all work items
  • No automatic permission scoping like Collections provide
  • Cross-release linked items may appear unexpectedly
See Configure Queries for advanced filtering patterns.

​
Option 3: Separate Projects

For strict isolation, create separate Polarion projects per release: 
MyProduct_v1.0 (Project)
MyProduct_v2.0 (Project)
MyProduct_v3.0 (Project)
Each project contains its own Risksheet documents, ensuring complete separation. Advantages:
  • Total isolation (permissions, queries, reports)
  • Clear organizational boundaries
  • No risk of cross-release data leakage
Limitations:
  • Difficult to share or reuse work items across releases
  • Increased administrative overhead
  • Traceability across releases requires cross-project linking
See Configure Multi-Project Setup for cross-project configuration patterns.

​
Feature Gap Impact Table

Workflow RequirementCollections Solve ThisCurrent Risksheet Workaround
Filter risks by release versionCollection-scoped queriesCustom field + query filtering
Show only items in target variantCollection membership checksBranching or custom field tagging
Apply release-specific permissionsCollection role inheritanceProject-level permissions only
Organize documents by product lineCollection folder structureSeparate projects or document folders
Track multi-variant configurationsCollection variant managementCustom multiEnum fields
Many teams use branching for major releases and custom field filtering for minor variants within each release. This hybrid approach balances isolation with flexibility.

​
Requesting Collections Support

If Collections support is critical for your workflow:
  1. Submit a feature request via Nextedy Support
  2. Describe your specific use case (multi-release, multi-variant, permission scoping, etc.)
  3. Provide business impact details to help prioritize development

​
Verification Steps

To confirm your chosen workaround is functioning:

​
For Branched Documents:

  1. Open a branched Risksheet document
  2. Verify that only work items from the baseline snapshot appear
  3. Check that linked items resolve to the correct historical revision

​
For Query Filtering:

  1. Open your Risksheet document
  2. Verify the displayed work items match your query filter (e.g., targetRelease:Release_2.0)
  3. Test editing a work item and ensure the custom field value is preserved

​
For Separate Projects:

  1. Open Risksheet documents in each project
  2. Verify that work items do not leak across projects
  3. Test cross-project linking if needed for traceability

​
See Also

Support TicketsSource Code
  • RisksheetDataStorage.java
  • AppConfigParser.ts