Configure Dynamic Expressions - Nextedy Documentation

Prerequisites

A working sheet configuration YAML file
Familiarity with the sheet configuration reference and data model reference

Understand the Two Expression Notations

Powersheet supports two distinct expression syntaxes, each used in a different configuration context:

Notation	Syntax	Used In
Context expression	`$context.property.path`	Data model configuration (constraints)
Dynamic value	`() => expression`	Sheet configuration (where, value, render, etc.)

Rule of ThumbIf you are editing a data model YAML file (entity types, relationships), use $context. If you are editing a sheet configuration YAML file (sources, columns, formatters), use () =>.

Add a Dynamic Where Clause to a Source Query

Dynamic where clauses let you filter source data using runtime values such as the current document or the current date.Filter by the current document:

sources:
  - id: opportunities
    query:
      from: Opportunity
      where:
        Module:
          "==": "() => context.document.moduleName"

When the sheet loads inside a LiveDoc, only records whose Module equals the current moduleName are returned.Filter by today’s date (show only future items):

sources:
  - id: tasks
    query:
      from: Task
      where:
        DueDate:
          ">": "() => new Date().toISOString()"

Date Format RequirementDynamic date values must return ISO 8601 format. Always call .toISOString() on Date objects. Returning a raw Date object will cause the query to fail silently.

Combine multiple document properties using template literals:

sources:
  - id: filtered
    query:
      from: EntityType
      where:
        Scope:
          "==": "() => `${context.document.moduleFolder}/${context.document.moduleName}`"

Set Dynamic Default Values with Entity Factory

Use entityFactory to pre-populate fields on newly created items with values resolved at runtime:

sources:
  - id: userNeeds
    query:
      from: UserNeed
    entityFactory:
      type: "() => context.source.type + '_VerificationTestCase'"
      Status: Planned

In this example, type is derived from the source entity’s type at runtime (for instance, a SystemRequirement source yields SystemRequirement_VerificationTestCase), while Status receives the static value Planned.

Add a Computed Column

The value property computes a column’s content from other properties on the current entity. On a column bound to a real property, the computed result is persisted back to the data source on save.

columns:
  total:
    value: "() => context.entity.count * context.entity.rate"
    title: Total
    format: "c0$"

The expression reads entity properties through context.entity. In this case it multiplies count by rate each time the sheet refreshes. A computed column is read-only by definition, so there is no need to declare isReadOnly.To compute a value that is shown but never stored, prefix the binding key with $. Such a column is unbound — it has no property behind it — so declare its result type with valueType:

columns:
  $riskScore:
    title: Risk Score
    value: "() => context.entity.Probability * context.entity.Severity"
    valueType: number

value is about data; render is about appearance.On a bound column, value modifies the underlying data — the computed result is saved. render only changes how an existing value is displayed and cannot supply content of its own. If the result should never be stored, make the column unbound with $ rather than reaching for render.

For the full walkthrough — result types, aggregation, and what an unbound column cannot do — see Add a Computed Column.

Add a Custom Renderer

Renderers produce custom HTML output for cell display. They do not affect persisted data.Inline render expression on a column:

columns:
  Priority:
    render: "() => '<b>' + context.value + '</b>'"
    title: Priority

Named renderer definition (reusable across columns):

renderers:
  linkedItems: "() => context.value.map((item) => `<b>${item.name}</b>`).join(', ')"

columns:
  relatedItems:
    render: linkedItems
    title: Related Items

Named renderers are defined in the top-level renderers section and referenced by name in the column render property.

Configure Conditional Formatting

Formatters apply styles to cells based on a boolean expression. Unlike value and render, formatter expressions use simplified syntax — they do not start with () =>.

formatters:
  criticalHighlight:
    expression: "context.entity.Probability <= 99"
    style: warningStyle

styles:
  warningStyle:
    color: red700
    backgroundColor: red100
    textDecoration: line-through

Apply the formatter to a column:

columns:
  Probability:
    title: Probability
    formatter: criticalHighlight

The formatter context provides access to context.document, context.entity, and context.value.

Use Context Expressions in Data Model Constraints

In data model YAML files, use the $context notation to create dynamic constraints that filter relationship data based on the source entity’s properties.Filter linked items to the same document component:

relationships:
  - from: DesignRequirement
    to: SystemRequirement
    back:
      name: designRequirements
      constraints:
        load:
          document:
            component: $context.source.document.component

When viewing a SystemRequirement from the “Braking” component, only DesignRequirement items from “Braking” documents are loaded.Filter by document name and folder:

constraints:
  load:
    document:
      moduleName: $context.source.document.moduleName
      moduleFolder: $context.source.document.moduleFolder

Constrain picker to same document type:

constraints:
  pick:
    document:
      type: $context.source.document.type

Per-Row Evaluation$context constraints are evaluated per row. Different rows can produce different constraint values depending on their source entity’s properties. This enables context-sensitive filtering without separate configurations.

Context Object Reference

The context object provides different properties depending on where the expression is evaluated:

Usage Location	`.user`	`.sources`	`.document`	`.entity`	`.value`	`.source`	`.row`
`where`	✅	✅	✅	—	—	—	—
`entityFactory`	✅	✅	—	—	—	✅	—
`value` (bound column)	✅	✅	—	✅	—	—	—
`value` (unbound column)	✅	✅	—	✅	—	✅	✅
`render` / `renderers`	—	—	—	✅	✅	—	—
`formatter`	—	—	✅	✅	✅	—	—
`display`	—	—	—	✅	✅	✅	—

Key context properties:

context.user — Current logged-in user (id, name)
context.document — Current document information (title, type, id, moduleName, moduleFolder, component)
context.entity — Current entity with all its properties, e.g., context.entity.severity
context.source — Parent/source entity — the level the current one was navigated from
context.row — The whole row, as context.row.entities[<level>] across every navigation level
context.value — Current cell’s display value. It is undefined inside a value expression, because that expression is what produces the value

Verification

After saving your configuration changes:

Reload the sheet in Polarion
For where clauses: verify that only matching records appear (try opening the sheet inside different documents)
For computed columns: confirm the column shows correct values and updates when the properties it reads change. A bound value column persists its result on save; an unbound ($) column leaves the work item untouched
For renderers: inspect cells for the expected HTML rendering
For formatters: verify that styling applies when the condition is met and disappears when it is not
For $context constraints: expand a relationship and confirm that only items matching the source entity’s document properties are loaded

You should now see dynamic values resolving correctly at runtime across all configured expression locations.

​Prerequisites

​Understand the Two Expression Notations

​Context Object Reference

​Verification

​See Also

Prerequisites

Understand the Two Expression Notations

Context Object Reference

Verification

See Also