Relationship types

Relation types define how asset types can connect to each other in the knowledge base.

Each relation type combines:

• A source asset type
• A relation name
• A target asset type

Example: Application enables Process

In the inventory, users then create real relations between assets that follow these relation types.

They let you model dependencies, hierarchy, ownership, or flow between assets.

Access

You can manage relation types in two places:

• Organization → Metamodel → "Relation types" to review all relation types across the metamodel
• An asset type → "Relations" to create and manage relation types from that source or target type

Create a relation type

1. Open "Relation types" or open an asset type and go to "Relations"
2. Click the create action
3. Choose the source and target asset types
4. Enter the relation name
5. Choose the color and arrow style
6. Click Create

If you create the relation type from an asset type page, that asset type is already used as one side of the relation.

You can customize the start marker, line style, and end marker to match your diagramming conventions.

Modify a relation type

1. Click the edit icon on the relation type
2. Update the attributes
3. Click Validate

Data impact

If you change the source or target asset type, existing relations between assets are deleted. If you only change the name, color, or arrow style, existing relations are preserved.

Delete a relation type

1. Click the delete icon
2. Click Confirm

danger

Deleting a relation type removes the corresponding relations from the inventory.

Example

To allow Applications to "enable" Processes:

1. Set the source asset type to Application
2. Enter the relation name Enables
3. Set the target asset type to Process

Result: Users can create Application enables Process relations in the inventory.

Relationship direction

Relation types are directional:

• Source: Origin asset type
• Target: Destination asset type

In diagrams and in the inventory, the relation goes from source to target.

A relation type should express one clear meaning in one direction. Choose that direction based on the business logic: who depends on what, who acts on what, who owns what, or what belongs to what. Once you choose that direction, use it consistently across the metamodel.

Recommended relationship types

Type	Usage	Example
Enables	Functional dependency	App → Process
Uses	Consumption	App → Data
Part of	Composition	Process → Capability
Responsible for	Ownership	Team → App
Precedes	Temporal succession or historization	Process → Process
Hosts	Infrastructure	Server → App

Best practices

When you define a relation type, start from the asset that does something, provides something, or carries the responsibility, then place the dependent, supported, contained, or affected asset on the other side. When possible, write relation types in the active voice.

For example, for infrastructure hosting, Server hosts Application is usually better than Application runs on Server because it follows a provider-to-dependent logic: the server provides the hosting, and the application depends on it. Application runs on Server can also be valid, but it expresses a different perspective: the runtime location of the application. Use that wording only if that is the main perspective you want to model.

• Use readable verbs
• Check the sentence formed by source, relation, and target
• Model one clear meaning per relation type and choose one direction for it
• Remember that a relation type belongs to a specific source-target pair
• Reuse the same relation name across pairs only when it keeps the same meaning
• Limit unnecessary relation types
• Use style and color to improve readability, not to compensate for unclear naming