> ## 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.

# Link Cardinality

> In Nextedy POWERSHEET, **link cardinality** defines how many instances of one entity type can be related to another.

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 <p className="mt-10 text-sm text-gray-400 dark:text-zinc-500 not-prose">
      Last reviewed on {formatted}
    </p>;
};

## Why Cardinality Matters

Siemens Polarion ALM allows any work item to link to any number of other work items through link roles. This open-ended flexibility means Polarion itself does not enforce limits like "a hazard must link to at least one risk control" or "a system requirement should derive from exactly one user need."

Powersheet's data model introduces cardinality as a semantic layer on top of Polarion's link roles. Think of it like database schema design: just as a relational database enforces foreign key constraints, Powersheet's cardinality settings enforce relationship multiplicity in the user interface.

## Cardinality Options

The `cardinality` property on a relationship definition accepts the following supported values:

<Frame>
  <img src="https://mintcdn.com/none-17b4493f/3Zik2OH750CE3kB4/powersheet/diagrams/concepts/link-cardinality/diagram-1.svg?fit=max&auto=format&n=3Zik2OH750CE3kB4&q=85&s=8082a35807fddb2143cd2a43931f8070" alt="diagram" style={{ width: "520px", maxWidth: "100%" }} width="520" height="260" data-path="powersheet/diagrams/concepts/link-cardinality/diagram-1.svg" />
</Frame>

| Cardinality    | From Side | To Side  | Typical Use Case                                        |
| -------------- | --------- | -------- | ------------------------------------------------------- |
| `many-to-one`  | Multiple  | Single   | Many design reqs derive from one system req             |
| `one-to-many`  | Single    | Multiple | One user need decomposes into many system reqs          |
| `many-to-many` | Multiple  | Multiple | Hazards linked to multiple risk controls and vice versa |

<Note title="one-to-one is not currently supported">
  Although `one-to-one` appears conceptually in the diagram above, it is not a supported cardinality value in the current Powersheet data model. Use `many-to-one` when you need a single-valued reference on the "from" side, or model uniqueness through validation rather than cardinality.
</Note>

## How Cardinality Is Defined

Cardinality is set on each relationship in the `relationships` array of the data model YAML:

```yaml theme={null}
relationships:
  - from: UserNeed
    to: SystemRequirement
    cardinality: one-to-many
    storage: linkedWorkItems
    linkRole: refines
    direct: systemRequirements
    back: userNeed
```

In this example, one `UserNeed` can link to many `SystemRequirement` items (one-to-many). The `direct` becomes a collection-valued property on `UserNeed`, while `back` becomes a single-valued property on `SystemRequirement`.

## Impact on the User Interface

Cardinality directly controls the sheet's editing behavior:

* **Single-value relationships** (the "one" side) display a single-select picker. The user can choose exactly one target entity.
* **Multi-value relationships** (the "many" side) display a multi-select picker. The user can select multiple related entities.

<Tip title="Cardinality is directional">
  A `many-to-one` relationship means the "from" entity can reference exactly one "to" entity, but the "to" entity can be referenced by many "from" entities. The navigation property on the "from" side is single-valued; the navigation property on the "to" side (via `back`) is collection-valued.
</Tip>

## Cardinality and Polarion Link Roles

Polarion link roles are inherently many-to-many -- any work item can create any number of links using a given role. Powersheet's cardinality setting does not change this at the Polarion level; instead, it enforces the constraint at the UI and validation level within the sheet.

This means:

* If a relationship is defined as `many-to-one`, the sheet will present a single-value picker and prevent users from creating additional links through the powersheet
* Links created outside Powersheet (via Polarion's native UI) are not retroactively constrained

<Info title="Verify in application">
  The exact enforcement behavior for cardinality violations (whether existing extra links are hidden or shown with a warning) may vary. Test with your configuration to confirm.
</Info>

## Common RTM Cardinality Pattern

A typical Requirements Traceability Matrix uses the following cardinality chain:

| From                | To                  | Cardinality    | Link Role   |
| ------------------- | ------------------- | -------------- | ----------- |
| `UserNeed`          | `SystemRequirement` | `one-to-many`  | `refines`   |
| `SystemRequirement` | `DesignRequirement` | `one-to-many`  | `refines`   |
| `Hazard`            | `RiskControl`       | `many-to-many` | `mitigates` |

This creates a hierarchy where each upstream requirement can decompose into multiple downstream items, while hazard-to-control relationships remain flexible.

## Related Pages

* [Entity Types and Relationships](/powersheet/concepts/entity-types-and-relationships) -- How entity types and relationships are structured
* [Process Constraints](/powersheet/concepts/process-constraints) -- Additional rules for loading, creating, and picking entities
* [Creating Your First Data Model](/powersheet/getting-started/first-data-model) -- Hands-on tutorial for setting up cardinality

***

<LastReviewed date="2026-07-02" />