Defining relationship types

Every organization has structure: teams own services, services depend on each other, domains group related capabilities. Relationship types are how Cortex models that structure, letting you define not just that two entities are related, but how they relate and what kinds of entities can participate.

Understanding relationship types in Cortex

A relationship type captures the semantics of a connection between entities: its directionality, the roles each side plays, and the constraints on what can appear at either end. Rather than treating all relationships as equivalent links, Cortex distinguishes between a few fundamentally different relationship patterns:

• Entity relationships - Customizable relationships (hierarchical or cyclical) between any entity types

• Team hierarchies - Hierarchical relationships specifically between teams, including ownership over other entities. Learn more in Understanding hierarchies.

• Domain hierarchies - Hierarchical relationships between domains, with optional inheritance so ownership can flow down from parent to child. Learn more in Viewing the domain hierarchy.

• Dependencies - Cyclical relationships between non-team entities. Learn more in Defining dependencies.

Want to learn more? Check out the Cortex Academy course on Catalogs, Entities, and Relationships.

Relationship direction: Source vs. destination

Every relationship has a direction. The source is the parent (the upstream entity), and the destination is the child (the downstream entity). For example, in a Repository relationship, a Service (source/parent) contains a Repository (destination/child).

This direction determines how the relationship is drawn in an entity's relationships graph, so define it carefully when creating a relationship type. If upstream and downstream appear reversed, the source and destination entities were likely defined in the opposite order.

Custom relationship type use cases

Relationship type	Description	Source	Destination
Repository	Mapping services to repositories to view the hierarchy of repos and the services they contain. For example, a service is linked to its code repository.	Service	Repository
Cloud account to resource	Associating cloud accounts (like AWS, Google Cloud Project, or Azure subscription) with their respective resources (such as EC2 instances or other cloud resources).	AWS account GCP Azure subscription	AWS resources (e.g., EC2) Google Cloud resources Azure resources
Service to environment	Linking services to their deployment environments.	Service	Environment
Monorepo	Mapping multiple services to a single repository.	Repository	Service
Service to endpoint	Associating services with their endpoints.	Service	Endpoint
Data center modeling	Representing data centers and their relationships to other infrastructure components.	Data center	Component

Use team ownership to represent ownership relationships, not custom relationship types.

Viewing relationship types

Viewing all configured relationship types

1. From the main sidebar, expand Catalogs, then select All entities.

2. Select the Relationship types tab.

   
3. Select a relationship type from the list to view more information.

Viewing relationships on entity pages

If an entity belongs to a relationship, you can explore that context directly from its entity details page.

1. Navigate to the entity's details page.

2. From the left entity details sidebar, select Relationships. Relationship types associated with the entity appear in the relationships graph.

In the example below, the entity California belongs to a relationship called Geography . Relationships default to graph view, giving you a visual map of parent/child connections, where sources (parents/upstream) connect to their destinations (children/downstream).

From the graph, click any entity to view a quick summary of its metadata. Select Go to entity to navigate directly to that entity's detail page.

Select Table view to see the same data in a structured list. This view is useful for quickly scanning or sorting related entities.

Entity relationship CQL

You can create Scorecard rules and write CQL queries based on entity relationships. See more examples in the CQL Explorer in Cortex.

Entity relationship destinations

All recursive destinations an entity for a relationship type, with an optional depth parameter to expand results

Definition - entity.destinations(relationshipType = "my-relationship")

Examples

You could write a Scorecard rule to ensure that an entity has at least one destination with the "my-relationship" type:

entity.destinations(relationshipType = "my-relationship").length > 0

Entity relationship sources

All recursive sources an entity for a relationship type, with an optional depth parameter to expand results

Definition - entity.sources(relationshipType = "my-relationship")

Examples

You could write a Scorecard rule that ensures an entity has at least one source with the "my-relationship" type:

entity.sources(relationshipType = "my-relationship").length > 0