Core Components

​

The four-component model

Every working powersheet setup relies on four collaborating elements. Each one can be configured independently, but they must reference each other correctly at runtime. The diagram shows the dependency flow: the domain model sits at the top because every other component ultimately depends on the entity types and relationships it defines. The sheet configuration references the domain model. Both Powersheet Drive and individual LiveDoc documents reference sheet configurations.

​

Domain model

The domain model is a YAML file that creates a semantic layer between Polarion’s native work item types and the structured entities that Powersheet works with. Think of it as a “lens” placed over the raw Polarion data — it does not create new work item types or modify existing ones. Instead, it maps them into a typed hierarchy that Powersheet can navigate, query, and enforce rules upon. A domain model declares three things:

• Entity types (domainModelTypes): each entry names an entity type and maps it to a Polarion work item type via the polarionType property. Entity types also declare their available properties — the fields that can appear as columns in the sheet.
• Relationships: connections between entity types that specify the from and to entity types, the cardinality (one-to-one, one-to-many, many-to-one, or many-to-many), the storage mechanism (typically linkedWorkItems using Polarion’s native link system), and the linkRole that identifies which Polarion link role stores the connection. Each relationship creates a pair of navigation properties — a direct property on the source entity and a back property on the target entity — enabling traversal in both directions.
• Constraints: optional rules that filter which work items appear in pick dialogs (picker constraints), controlling what users can select. Picker constraints can filter by document properties such as moduleFolder, moduleName, type, or component. The component constraint supports dynamic context references like $context.source.document.component for runtime-resolved filtering.

Domain models are managed in Administration > Nextedy POWERSHEET > Domain Models and can be scoped to a specific project or shared globally across all projects.

​

The standard RTM example

Throughout this documentation, the standard Requirements Traceability Matrix (RTM) example is used to illustrate concepts. It defines five entity types linked in a chain: UserNeed —> SystemRequirement —> DesignRequirement —> Hazard —> RiskControl Each arrow represents a relationship with defined cardinality, link role, and navigation properties. This hierarchy models a typical regulated-industry traceability chain from high-level needs through system-level requirements, design artifacts, and risk management entities. For a complete YAML reference of this model, see Example Models Reference.

​

Sheet configuration

The sheet configuration is a separate YAML file that controls what users see and how they interact with the data. While the domain model defines the data landscape, the sheet configuration defines the data presentation. It references entity types and navigation properties from the domain model and specifies:

• Columns: each column is identified by a binding path — a dot-separated key that maps to a domain model property or navigates through a relationship. For example, title binds to a direct property, while systemRequirements.systemRequirement.severity traverses a relationship to reach a property on a related entity. Each column definition supports properties including title (display header), width (pixel width), minWidth (minimum responsive width), visible (default visibility), formatter (conditional styling reference), columnGroup (visual grouping assignment), multiItem (for one-to-many relationship columns), and isReadOnly (edit protection).
• Sources: data source definitions that connect the sheet to its domain model. Each source specifies a model reference (the domain model name), a query (which entity type to load as the root), and an expand tree (which relationships to follow when fetching data). The expand tree determines the depth and breadth of hierarchical data loading.
• Views: named presets that control which columns are visible for a given analysis perspective. Multiple views can exist within a single sheet configuration, allowing users to switch between different column sets without creating separate configurations.
• Column groups (columnGroups): visual groupings that cluster related columns under a shared header. Each group has a groupName, optional groupStyle and headerStyle for color theming, and a collapseTo property that specifies which column remains visible when the group is collapsed.
• Sort order (sortBy): default sort configuration specifying the column and direction (asc or desc) for initial row ordering.

Sheet configurations are managed in Administration > Nextedy POWERSHEET > Sheet Configurations and follow the same project or global scoping as domain models.

​

Powersheet Drive

Powersheet Drive is a sidebar navigation panel that gives users a central place to discover and open all powersheet documents in their project. It queries for Polarion documents that have the nextedySheetConfig custom field populated and presents them in a drive-style navigator. Powersheet Drive becomes available once the powersheet topic is added to the project’s navigation views in Polarion administration. From the user’s perspective, it functions like a file browser scoped to powersheet documents, showing document names, folder paths, and the assigned configuration.

​

LiveDoc (document entry point)

Each powersheet is anchored to a Polarion LiveDoc — a standard Polarion module document. What makes a LiveDoc into a powersheet document is the presence of the nextedySheetConfig custom field, which holds the identifier of a sheet configuration file. When a user opens this document through Powersheet Drive, the application reads the configuration reference, loads the associated domain model, executes the data query, and renders the interactive sheet. The PowersheetService handles document management operations: creating new powersheet documents, duplicating from templates, and retrieving document metadata. When creating a document, the service assigns the appropriate module type (defaulting to the type containing powersheet), sets the configuration reference, and generates document URLs in the format /polarion/#/project/{projectId}/powersheet?document={path}&documentTitle={title}. Documents can also include an “Open with Nextedy POWERSHEET” button via a Velocity macro, providing bidirectional navigation between the standard LiveDoc view and the sheet view.

​

How the components connect at runtime

When a user opens a powersheet document, the loading sequence follows a deterministic chain: The key steps in detail:

1. The user selects a document from Powersheet Drive (or navigates directly to the document URL)
2. The application reads the nextedySheetConfig custom field value from the LiveDoc to identify which sheet configuration to use
3. The sheet configuration YAML is loaded and parsed, extracting column definitions, source configurations, views, and formatters
4. The sources[].model property in the sheet configuration identifies the domain model by name; the domain model YAML is loaded and its entity types are translated into a metadata structure
5. A data guard component monitors initialization state and blocks rendering until the metadata system is ready. Once ready, the data source query executes (expanding relationships as defined in the source expand tree), columns are resolved against entity metadata, and the interactive sheet renders

​

Separation of concerns

The split between the domain model and the sheet configuration is a deliberate architectural decision. It enables two important patterns: One domain model, many sheet configurations. A single domain model defining the RTM entity hierarchy can serve multiple sheet configurations — one for requirements review (showing requirement-focused columns), another for risk analysis (showing hazard and risk control columns), and a third for traceability auditing (showing link completeness columns). All three sheets share the same underlying entity types and relationships. One project, many domain models. A project can host multiple domain models for unrelated concerns. A requirements traceability domain model and a risk management domain model can coexist, each with its own entity types, relationships, and sheet configurations. This separation also means that changes to presentation (adding a column, creating a new view, adjusting column widths) never require modifications to the data structure. And changes to the data structure (adding a new entity type, defining a new relationship) do not automatically affect existing sheets — columns must be explicitly added to display new data. For a detailed comparison of what belongs in which file, see Data Model vs Sheet Configuration. For practical tutorials on building each component, see the Getting Started section. For the complete YAML property reference, see the Sheet Configuration Reference and Data Model Reference.

Sources

Source Code: DomainModelV2.java, whole_rtm.template.yaml, Powersheet.tsx, SheetComponent.tsx, ViewModel.ts, PowersheetService.javaTickets: Configuration setup guidance, domain model configuration support, first-time setup troubleshooting