Maps the domain model entity type to one or more Polarion work item type IDs. When omitted, the entity type name is used as the Polarion type ID. Accepts both scalar and array formats.
polarionProto
string
IWorkItem.PROTO
Specifies the Polarion prototype (object type) this entity maps to. Determines which class of Polarion objects this entity can represent. Valid values are enumerated from the Polarion platform at runtime.
name
string
Derived from map key
Unique identifier for the entity type. Set automatically from the YAML map key. Referenced by relationships[].from and relationships[].to fields.
When polarionType is omitted, the entity type name (the YAML map key) is used as the Polarion work item type ID. For example, an entity named Task with no explicit polarionType maps to Polarion work item type Task.
In this configuration, the UserNeed entity type maps to the Polarion work item type ID user_need. All queries for UserNeed entities resolve to work items of type user_need.
A single entity type can map to multiple Polarion work item types by providing an array. This enables a unified view over work items of different types:
Queries for the Requirement entity type return work items matching any of the listed types
The first type in the array is used as the default when creating new work items
All listed type IDs must exist in the Polarion project configuration
When an entity maps to multiple Polarion types, queries produce a combined result set. Filter predicates and constraints apply uniformly across all mapped types. Properties referenced in column bindings must exist on all mapped types, or the value will be empty for types that lack the field.
For complete guidance on multi-type entity configuration, see Multi-Type Entities.
The Hazard entity maps to Polarion work item type Hazard. This convention works when the entity type name exactly matches the Polarion work item type ID defined in the project.
The polarionProto property specifies which Polarion prototype (object class) the entity represents. Most entity types use the default IWorkItem.PROTO, but special object types require an explicit prototype.
polarionProto Value
Polarion Object
Use Case
IWorkItem.PROTO (default)
Work item
Standard entity types (requirements, risks, controls)
Other prototype values
Non-work-item objects
Special Polarion object classes
Available prototype values are enumerated from the Polarion platform at runtime. The JSON schema generator reads all valid prototype names to populate the polarionProto enum constraint for IDE validation.
The JSON schema generated by Powersheet validates polarionProto values against the set of prototypes available on the Polarion server. When editing domain model YAML files with schema support enabled, the IDE provides:
Autocomplete for valid polarionProto values
Validation errors for unrecognized prototypes
Type checking for polarionType (accepts both string and array)
Powersheet recognizes several built-in entity types that map to Polarion objects. These types have specialized handling in the query processor and metadata system.
Entity Type
Polarion Object
polarionType Support
Notes
Document
Polarion module (LiveDoc)
Yes
When polarionType is set, it references a concrete document type. Container for work items.
Project
Polarion project
N/A
Project-level metadata and properties.
The Document entity type supports polarionType. When set, it filters documents to those matching a specific document type ID. This is useful for constraining picker dialogs and queries to a particular class of documents.
The from and to fields in relationships must use domain model entity type names (UserNeed, SystemRequirement), not Polarion work item type IDs (user_need, sys_req). Powersheet resolves the Polarion type mapping internally when executing queries.
Before any query executes, Powersheet checks that the current user has read permission for the entity type being queried. Entity types can have permission annotations that restrict access. See Permissions for details.
When a currentDocConstraint parameter is provided, the query processor restricts results to work items within a specific document. The constraint can reference either an entity type name or a navigation property path. Combined with polarionType, this enables document-scoped views over specific work item types.
These are the most frequent type mapping errors encountered during initial setup:
Rule
Description
polarionType must match Polarion configuration
Type IDs must correspond to work item types defined in the Polarion project. Mismatched IDs produce empty query results.
Entity type names are case-sensitive
UserNeed and userneed are different entity types. Use PascalCase consistently.
sources.model must match model name
The model property in sheet sources must reference the correct domain model file name, not the default rtm.
Document constraints use type ID
When configuring document constraints, use the document type ID (e.g., softwareRequirementsSpecification), not the display name (e.g., “Software Requirements Specification”).
Multi-item columns for duplicate link types
When two different entity types link to the same parent entity via the same link role, the second column must use multiItem: true in the sheet configuration.
The polarionType mapping interacts with relationship cardinality to determine how columns display data. The cardinality of the relationship between entity types determines the expand pattern and column binding syntax used in sheet configurations.
