Skip to main content

​
Step 1: Open the Domain Model

  1. Navigate to Administration > Nextedy POWERSHEET > Domain Models
  2. Select the domain model you want to edit
  3. Locate the entity type under domainModelTypes where you want to add constraints

​
Step 2: Understand the Three Constraint Stages

Powersheet supports three constraint stages, each controlling a different operation:
StagePurposeEffect
loadFilters which entities are visible in the sheetOnly matching entities appear when data loads
pickFilters picker dialog optionsOnly matching items appear in relationship pickers
createSets defaults for new entitiesNew items are created in the specified document location
diagram
Stages cascade upward: pick inherits load constraints, and create inherits both load and pick. If no create constraints are defined, the system falls back to pick constraints for the create stage.

​
Step 3: Add Load Constraints

Load constraints filter which entities are visible when data loads into the sheet. Add a constraints block with load to the entity type: 
domainModelTypes:
  UserNeed:
    polarionType: userNeed
    properties:
      description:
    constraints:
      load:
        document:
          type: stakeholderRequirement
With this constraint, only UserNeed work items that exist in documents of type stakeholderRequirement will appear in the sheet.

​
Step 4: Add Pick Constraints

Pick constraints filter what appears in relationship picker dialogs. This is useful when users link entities and you want to restrict which items they can select: 
domainModelTypes:
  SystemRequirement:
    polarionType: systemRequirement
    properties:
      description:
      severity:
    constraints:
      pick:
        document:
          moduleFolder: Requirements
          type: systemSpecification
This ensures that when a user picks a SystemRequirement through a relationship picker, only items from the Requirements space in documents of type systemSpecification are shown.

​
Step 5: Add Create Constraints

Create constraints specify the default document location when new items of this type are created through the sheet: 
domainModelTypes:
  DesignRequirement:
    polarionType: designRequirement
    properties:
      description:
    constraints:
      create:
        document:
          moduleFolder: Design
          moduleName: Design Specification
          type: designSpecification
When a user creates a new DesignRequirement from the sheet, it will be placed in the Design Specification document within the Design space.

​
Step 6: Combine Multiple Stages

You can define multiple constraint stages on the same entity type. Each stage applies to its respective operation, and cascading applies automatically: 
domainModelTypes:
  SystemRequirement:
    polarionType: systemRequirement
    properties:
      description:
      severity:
    constraints:
      load:
        document:
          type: systemSpecification
      pick:
        document:
          moduleFolder: Requirements
      create:
        document:
          moduleFolder: Requirements
          moduleName: System Requirements Spec
          type: systemSpecification
In this example:
  • Load stage: only system requirements from systemSpecification documents are visible
  • Pick stage: inherits the load filter, plus restricts to the Requirements space
  • Create stage: inherits both, plus targets a specific document name

​
Step 7: Use Comparison Operators

Constraint values support five comparison operators beyond exact matching:
OperatorBehaviorExample
(default)Exact equalitytype: systemSpecification
containsSubstring matchmoduleName: { contains: Spec }
inMatches any value in a listtype: { in: [systemSpec, designSpec] }
startsWithPrefix matchmoduleFolder: { startsWith: Req }
endsWithSuffix matchmoduleName: { endsWith: Specification }
When you use a plain string value (e.g., type: systemSpecification), the equals operator is applied by default. To use another operator, wrap the value in an operator object: 
constraints:
  load:
    document:
      type:
        in: [systemRequirementsSpecification, designRequirementsSpecification]
      moduleName:
        contains: Specification

​
Step 8: Use Logical Operators

Multiple properties within the same document block are combined with AND logic — all conditions must match simultaneously. For OR logic, use the or keyword inside the document block to match entities from multiple locations: 
constraints:
  pick:
    document:
      or:
        - moduleName: Alpha Requirements
        - moduleName: Beta Requirements
This matches work items from either the “Alpha Requirements” or “Beta Requirements” document.
If you define constraints that conflict with each other (for example, specifying a moduleFolder that does not contain any documents of the specified type), the result set will be empty. No error is raised — the picker simply shows no items. Always verify your constraint combinations against your actual Polarion project structure.

​
Step 9: Use Dynamic Context References

For component-scoped relationships, use $context.source.document.component to dynamically filter based on the source entity’s document component: 
domainModelTypes:
  SystemRequirement:
    polarionType: systemRequirement
    constraints:
      pick:
        document:
          component: $context.source.document.component
This ensures picker results are scoped to the same component as the source entity’s document. For example, if a user is editing a UserNeed in a document with component “Braking System”, the picker will only show system requirements from documents that also belong to the “Braking System” component.
Dynamic context references are particularly useful in multi-component projects where each subsystem has its own set of documents. They prevent users from accidentally linking to entities outside their component scope.

​
Constrainable Document Properties

The document block in constraints supports the following properties:
PropertyDescription
moduleFolderThe space (folder) where the document resides in the project hierarchy
moduleNameThe exact name of the target document
typeThe document type ID (as defined in Polarion configuration)
idThe document ID in folder/name format
titleThe document display title
componentThe component property of the document, often used with $context
The type property must use the document type ID (e.g., systemSpecification), not the human-readable display name (e.g., “System Specification”). Using the display name will silently produce no matches. Check your Polarion project configuration under Administration > Document Types for the correct type IDs.
Begin with a working domain model that has no constraints, then add pick constraints first (easiest to test via the picker dialog), followed by create and load constraints. This makes it straightforward to identify which constraint is causing unexpected behavior.

​
Verification

After saving the domain model with constraints:
  1. Open a sheet that uses this domain model
  2. For load constraints: verify that only matching entities appear in the sheet rows
  3. For pick constraints: click a relationship picker cell and verify the dropdown shows only items matching your filter criteria
  4. For create constraints: create a new item through the sheet and verify it appears in the expected document location
You should now see constraints actively filtering entities according to your configuration. If pickers show no results or the sheet loads with no data, review the constraint properties against your actual Polarion project structure — particularly the type ID and moduleFolder values.

​
See Also

KB ArticlesSupport TicketsSource Code
  • DomainModelTypeV2.java
  • DomainModelV2.java
  • Relationship.java
  • Direction.java