Skip to main content
diagram

Context Object Structure

The context object is a hierarchical namespace that Powersheet populates at runtime. Different properties become available depending on where the expression is evaluated.

Context Properties Reference

Two Expression Notations

Powersheet uses two distinct notations for dynamic expressions, each tied to a specific configuration context.
If you are editing a data model YAML file (domainModelTypes, relationships), use $context. If you are editing a sheet configuration YAML file (sources, columns, formatters), use () =>.

Context Expression ($context)

Context expressions use dot-notation to access properties from the runtime context. They are used exclusively in data model constraint definitions. No JavaScript logic is supported --- only direct property access. Where it is used:
  • domainModelTypes.*.constraints --- entity type constraints
  • relationships.*.direct.constraints / relationships.*.back.constraints --- relationship constraints
Available $context paths:
Dynamic constraints with $context are evaluated per-row. Different rows can produce different constraint values depending on their source entity’s properties.

Dynamic Value (() => expression)

Dynamic values use JavaScript arrow function syntax and are evaluated in sheet configuration contexts. They receive the context object and offer full JavaScript expressiveness for computing values, filtering data, and rendering content at runtime. Where it is used:

Context Availability Reference

Not all context properties are available in every expression location. The following reference shows which properties are accessible where:
Referencing a context property that is not available in the current location returns undefined. This does not produce an error but may cause unexpected behavior in your expressions. Always consult the table above.

Document Context

Powersheet automatically provides document context information to queries and expressions. When a sheet is embedded in a Polarion LiveDoc, the context.document properties are populated from the hosting document. The two most commonly used properties in dynamic where clauses are context.document.moduleName and context.document.moduleFolder, which identify the hosting document by name and folder path.

Document Scoping in Constraints

The applyCurrentDocumentTo constraint property controls whether queries are automatically filtered to the current document:
When applyCurrentDocumentTo matches the query’s from entity type, the query engine injects predicates for document.moduleFolder and document.moduleName to restrict results to items within the current document.

Document ID in Dynamic Expressions

The document ID is available as context.document.id in dynamic value expressions and as a query parameter for server-side resolution:
For details on document constraint variants, see Document Filtering.

Project Scoping

All queries executed through Powersheet are automatically scoped to the current Polarion project. The query engine adds a project.id filter to every Lucene query, ensuring results only include entities from the active project. This scoping is applied transparently and does not require explicit configuration.

Dynamic Value Examples

Filtering by Current Document (Module Name)

The most common dynamic where clause restricts a query to items in the hosting LiveDoc. Use context.document.moduleName to match the document by name:
For a more precise match that also pins the folder path, combine moduleName with moduleFolder:

Using column.display for Document and Chapter References

The column.display option is the standard way to control how a navigation property is rendered in a cell. For document references, display: titleOrName renders the document’s title when available and falls back to the module name:
For chapter references, display: title renders the chapter heading text:
These named display modes are preferred over dynamic expressions whenever a column simply needs a standard label for a linked entity.

Filtering by Date

Dynamic date calculations use JavaScript date functions. The resulting value must match the data type format --- for dates, use .toISOString():

Setting Initial Values for New Entities

The entityFactory property sets default values when creating new work items. The factory re-evaluates dynamically based on the parent entity, so context-sensitive defaults are typically derived from context.source:
Here, the new test case title is composed from the parent entity’s work item type, so creating a verification case under different sources produces different default titles.

Calculated Column Values

The formula property computes a value from other properties on the current entity:
The formula property writes the calculated value back to the data source. Use render if you only need to change how a value is displayed without modifying the underlying data.

Custom Cell Rendering

The render property and named renderers produce custom HTML output:

Display Override for Navigation Properties

When the standard display: titleOrName / display: title shorthands are not sufficient, the display property accepts a dynamic expression that overrides what is shown for a linked entity column:

Conditional Formatting

Formatter expressions use a simplified syntax without the () => prefix. The expression is evaluated as a boolean condition:
Formatter expressions do not start with () =>. They are evaluated directly as boolean conditions against the context object.

Context Expression Examples (Data Model)

Filter by Source Document Component

Restrict linked items to the same document component as the source entity:
When viewing a SystemRequirement from the “Braking” component, only DesignRequirement items from “Braking” documents are loaded.

Filter by Source Document Identity

Restrict to the exact same document as the source entity:

Filter by Source Document Type

Restrict picker results to documents of the same type as the source entity’s document:

Quick Reference

Last modified on July 10, 2026