Skip to main content

​
Two files, two concerns

At its simplest, the distinction is:
Domain ModelSheet Configuration
PurposeDefines what data existsDefines how data is displayed
ContainsEntity types, relationships, constraintsColumns, sources, views
YAML root keysdomainModelTypes, relationshipscolumns, sources, views
Managed inAdministration > Nextedy POWERSHEET > Domain ModelsAdministration > Nextedy POWERSHEET > Sheet Configurations
ScopeProject or GlobalProject or Global
The domain model describes the structure of your data: what entity types exist, what properties they have, how they relate to each other, and what Siemens Polarion ALM work item types they map to. The sheet configuration describes the presentation: which columns appear, what data source to query, and how to expand relationships for display. diagram

​
Why separate files?

The separation enables several important patterns:

​
One domain model, many sheet configurations

A single domain model — for example, one defining UserNeed, SystemRequirement, DesignRequirement, Hazard, and RiskControl — can power multiple sheet configurations:
  • An RTM overview sheet showing all five entity types in a traceability matrix
  • A risk analysis sheet focusing only on Hazard and RiskControl
  • A requirements authoring sheet showing UserNeed and SystemRequirement with editing enabled
Each sheet configuration references the same domain model via the model property in its sources section, but presents different columns and views.

​
One sheet configuration, many projects

Because the domain model maps abstract entity type names (like SystemRequirement) to concrete Polarion work item types (like sys_req or systemRequirement), the same sheet configuration can work across projects that have different Polarion type names. Each project just needs its own domain model with the correct polarionType mappings.

​
Independent change cycles

Changing a column width, adding a new view, or reordering columns only touches the sheet configuration. Adding a new entity type or relationship only touches the domain model. This means:
  • Presentation changes do not risk breaking the data structure
  • Structural changes do not require updating every sheet that uses the model

​
The reference point: sources

The sheet configuration connects to the domain model through the sources section: 
sources:
  - model: rtm
    query:
      from: UserNeed
    expand:
      - systemRequirements:
          expand:
            - systemRequirement
The model value is the name of the domain model file. The query.from value is an entity type name from domainModelTypes. The expand tree uses navigation property names defined in the domain model’s relationships section.
A common source of errors is mixing up Polarion work item type IDs with domain model entity type names. The query.from value must be the entity type name (e.g., UserNeed), not the Polarion type (e.g., userNeed). Similarly, expand entries must use the navigation property names (fromNavPropName/toNavPropName), not the relationship definitions themselves.

​
Column binding paths

Columns in the sheet configuration use binding paths that trace a route through the domain model:
Binding pathMeaning
titleThe title property of the root entity type
severityThe severity property of the root entity type
systemRequirements.systemRequirementNavigate to related SystemRequirement via the systemRequirements navigation property
systemRequirements.systemRequirement.severityThe severity of the related SystemRequirement
Each segment in a dot-separated path must correspond to either a property or a navigation property name defined in the domain model. If the path does not resolve against the metadata, the column will not display data.

​
The enum provider connection

When a document has the nextedySheetConfig custom field, it uses a dynamic enum provider named Nextedy - Sheet Config that scans the repository for available YAML configuration files. This provider discovers both project-level and global configurations:
  • Project configurations: shown by filename (e.g., rtm-sheet)
  • Global configurations: shown with a (Global) suffix (e.g., rtm-sheet (Global))
No default configuration is pre-selected — users must explicitly choose one. This explicit assignment ensures that every powersheet document has a deliberate configuration choice rather than an accidental default.

​
Common misconceptions

Based on support patterns, these misunderstandings frequently cause configuration errors:
The domainModelTypes names (e.g., UserNeed) and Polarion work item type IDs (e.g., userNeed) serve different purposes. The domain model name is used in relationships and sheet configurations. The Polarion type ID goes only in the polarionType property.
In the relationships section, from and to values must match keys in domainModelTypes, not Polarion type IDs. Using the wrong reference produces “left error” (invalid from) or “right error” (invalid to) messages.
When building both files from scratch, follow the Incremental Configuration Approach. Start with one entity type and two columns, verify everything works, then add complexity one layer at a time.

​
Further reading

KB ArticlesSupport TicketsSource Code
  • prod-powersheet-src/com.nextedy.powersheet/src/com/nextedy/powersheet/PowersheetService.java
  • prod-powersheet-src/com.nextedy.powersheet.client/ltc-repo/packages/common/types/api/document.ts
  • prod-powersheet-src/com.nextedy.powersheet.client/cypress/fixtures/configurations/constraints_composing.template.yaml
  • prod-powersheet-src/com.nextedy.powersheet/src/com/nextedy/powersheet/enumProvider/SheetConfigEnumProvider.java
  • riskmanagement_model.yaml