DemandFlow Support Centre

Relationship Types

DemandFlow has four distinct mechanisms for relating objects to each other. Each fits a different shape of relationship, and a single entity may use several of them.

1. comboKey hierarchy, strict parent → child

The most common pattern. A child object's comboKey embeds its parent's id. Querying "all children of X" is a prefix query.

• Cardinality: one parent → many children.
• Stored: in the child's comboKey string.
• Querying: list endpoint with the prefix that includes the parent.
• When to use: a true ownership / containment relationship. A patent application belongs to exactly one patent. A project belongs to exactly one portfolio.

See comboKey: Hierarchical Relationships for the format and rules.

2. LINK objects, bidirectional many-to-many

For relationships that don't fit a strict parent-child shape, DemandFlow uses a separate object with entity = "LINK" that joins two objects, queryable from either side.

• Cardinality: many ↔ many. A person can be linked to many companies; a company can be linked to many people.
• Stored: a LINK record with comboKey indexed from side A and comboKey2 indexed from side B.
• Querying: list LINK records under either side's comboKey, then dereference the other id.
• When to use: the relationship has no natural "owner", or you need to traverse from either side cheaply.

See LINK Objects: Bidirectional Joins.

3. Foreign-key fields, single reference

An entity-specific field that stores another object's id. The relationship is one-way: you can navigate from the holder to the referenced object, but not back without a separate query.

• Cardinality: many → one. A KB article references one category; a task references one assignee.
• Stored: as a UUID string in a custom field on the holder. Common field names include category, assigned, parent, or anything entity-specific.
• Querying: read the holder, then GET the referenced id.
• When to use: a flat lookup with no need for fast reverse navigation.

Foreign-key fields are not indexed for reverse lookup. To find "every article in category X" you typically use comboKey hierarchy or a full list scan with a filter.

4. Embedded arrays, composition

Some entities carry arrays of small structured records as a field on the parent object. These are not separate objects, they have no id in the global sense and no independent comboKey.

• Cardinality: one → many, fully owned.
• Stored: as an array on a custom field of the parent.
• Querying: read the parent and walk the array in your client.
• When to use: the children only make sense in the context of the parent, are bounded in count, and never need to be queried independently.

Choosing between them

See also

• The DemandFlow Object Model
• System Fields
• comboKey: Hierarchical Relationships
• Object Levels
• Relationship Types
• LINK Objects: Bidirectional Joins
• Versioning and Timestamps