> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # Core Components > Nextedy POWERSHEET provides a structured, configurable sheet interface over Siemens Polarion ALM data. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; ## 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. diagram The diagram shows the dependency flow: the data model sits at the top because every other component ultimately depends on the entity types and relationships it defines. The sheet configuration references the data model. Both Powersheet Drive and individual LiveDoc documents reference sheet configurations. ## Data model The **data 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 data 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. Data models are managed in **Administration > Nextedy Powersheet > Data Models** and can be scoped to a specific project or shared globally across all projects. A common misconception is that the data model determines which columns appear in the sheet. It does not -- the data model defines *what data exists and how it connects*. Which columns are visible, how they are labeled, and how they behave is the responsibility of the sheet configuration. ### 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](/powersheet/reference/example-models/index). ## Sheet configuration The **sheet configuration** is a separate YAML file that controls what users see and how they interact with the data. While the data model defines the data landscape, the sheet configuration defines the data *presentation*. It references entity types and navigation properties from the data model and specifies: * **Columns**: each column is identified by a binding path -- a dot-separated key that maps to a data 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 data model. Each source specifies a `model` reference (the data 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 data models. The `sources[].model` property in the sheet configuration must match the exact name of the data model, not the default `rtm`. A mismatch here is one of the most common first-time configuration errors -- the sheet will fail to load metadata and display no data. ## 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. The query used by Powersheet Drive to discover documents is configurable via project properties. The default behavior finds all documents with the `nextedySheetConfig` field populated. ## 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 data 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: diagram 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 data model by name; the data 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 | Component | Managed in | References | | ------------------- | -------------------------------------------------------------- | ---------------------------------------------------- | | Data model | **Administration > Nextedy Powersheet > Data Models** | Polarion work item types, link roles | | Sheet configuration | **Administration > Nextedy Powersheet > Sheet Configurations** | Data model (by name) | | LiveDoc | Project documents | Sheet configuration (via `nextedySheetConfig` field) | | Powersheet Drive | **Administration > Portal > Topics** | Documents with `nextedySheetConfig` set | ## Separation of concerns The split between the data model and the sheet configuration is a deliberate architectural decision. It enables two important patterns: **One data model, many sheet configurations.** A single data 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 data models.** A project can host multiple data models for unrelated concerns. A requirements traceability data model and a risk management data 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. When starting a new Powersheet setup, begin with the simplest possible configuration: a data model with a single entity type and a sheet configuration with a few columns. Validate that the basic setup loads correctly before adding relationships, expansion paths, and additional entity types. This incremental approach significantly reduces misconfiguration errors during initial setup. For a detailed comparison of what belongs in which file, see [Data Model vs Sheet Configuration](/powersheet/concepts/data-model-vs-sheet-config). For practical tutorials on building each component, see the [Getting Started](/powersheet/getting-started/index) section. For the complete YAML property reference, see the [Sheet Configuration Reference](/powersheet/reference/sheet-config/index) and [Data Model Reference](/powersheet/reference/data-model/index).