🤝Relationships

In Euno, the data model is made up of resources, each identified with a Universal Resource Identifier. Between these resources there are relationships.

These relationships form the foundation of Euno’s graph-based understanding of the data stack. There are five primary types of relationships:

1. Dependency

A dependency relationship exists when one resource relies on another. For example, a database view created by joining three tables will have three dependency relationships pointing from the view to each table.

If resource A depends on resource B, A is said to be downstream of B, and B is upstream of A.

A single resource may have zero, one, or many dependencies—technically a many-to-many relationship.

Examples of using upstream and downstream queries:

• To find the upstream of a resource: has upstream(uri="<resource-uri>")

• To find the downstream of a resource: has downstream(uri="<resource-uri>")

Column-Level Dependencies

Euno also supports fine-grained, column-level dependency tracking using the attributes upstream_fields and downstream_fields. These relationships capture dependencies between individual fields (such as columns, measures, or dimensions), or between fields and visualizations (such as Tableau views or Looker Looks).

For instance:

• A column in a table used in a Tableau view would create a dependency from the view to the column.

• A measure in a Looker Look based on multiple columns would be downstream of those columns.

Examples of using upstream_fields and downstream_fields:

• To find the visualizations in Tableau that use a specific field: type="tableau_view" and has upstream_fields(uri="<resource-uri>")

• To find all the fields used in a Tableau view: type="tableau_field" and has downstream_fields(uri="<resource-uri>")

Note: If a resource has both column-level lineage and regular lineage, and you want to return all relevant resources, you need to include both types of queries. For example: has downstream_fields(uri="<resource-uri>") or has downstream(uri="<resource-uri>")

Statement-level dependencies for table resources

For SQL-based table resources (for example, warehouse views), Euno also captures field dependencies that come from statement logic, not only projected fields. This means fields used in clauses like JOIN, WHERE, GROUP BY, HAVING, QUALIFY, and ORDER BY can appear in table-level upstream_fields relationships even when they are not selected in the final projection.

Example

If a view is defined as:

SELECT order_id, customer_id FROM proj_sales.analytics.orders_raw WHERE order_status = 'COMPLETE'

you may see a table-level upstream field relationship to the source column orders_raw.order_status, because that field is part of the statement logic.

Task-level dependencies

Orchestration tools also expose the order in which their tasks run. Task A is an upstream task of task B when B runs after A in the same pipeline, and B is a downstream task of A. Today this is observed for Airflow tasks within a DAG (the upstream_task_ids attribute). This is execution order, not data lineage: a task's data inputs and outputs are still expressed through has upstream / has downstream on the tables and datasets it reads and writes.

• To find the tasks that must run before a given task: type="airflow_task" AND has downstream_task(uri="<task-uri>")

• To find the tasks that run after a given task: type="airflow_task" AND has upstream_task(uri="<task-uri>")

2. Containment

A resource can be contained within another resource. For example, a column is contained in a table, and a table is contained in a schema.

When two resources, A and B, have a containment relationship such that A contains B, we say that A is the parent of B, and B is a child of A.

A resource can have zero, one, or many children, and zero or one parent. In technical terms, this is an optional many-to-one relationship.

Examples using the containment relationship:

• To find all the resources inside a workbook: has parent(type="tableau_workbook" and uri="<resource-uri>")

• To return all the fields in a table: has parent(type="table" and uri="<resource-uri>")

3. Defined-by

The defined by relationship links a resource to the entity that defines it. It is used when one resource determines the structure or existence of another.

For example, a Snowflake table created via a dbt model will have a defined by relationship pointing from the table to the dbt model. Conversely, the dbt model is considered the definer of the table.

It is possible for a resource to have multiple definers.

Example:

• To find the dbt resource that defines a specific table in the warehouse: type~"dbt" and has defined(type="table" and uri="<resource-uri>") or type~"dbt" and is definer of(type="table" and uri="<resource-uri>")

• To find the table that is defined by a dbt model: type="table" and has definer(type~"dbt" and uri="<resource-uri>") or type="table" and is defined by(type~"dbt" and uri="<resource-uri>")

This relationship helps trace logical definitions across tools, and surfaces authoritative sources within your data stack.

4. Usage

A usage relationship exists when a user interacts with or uses a resource. This relationship tracks which users are accessing which resources, providing insights into resource utilization and user behavior.

If resource A (a user) uses resource B, A is said to be a user of B, and B is used by A.

A resource can be used by zero, one, or many users—technically a many-to-many relationship.

Examples of using user and used queries:

• To find all users of a specific resource: type="user" AND is user of(type='tableau_dashboard' AND uri="<resource-uri>")

• To find all resources used by a specific user: type="tableau_view" AND is used by(name="[e-mail]")

Timeframe specification: For usage relationships, you can limit results to a specific time period by adding -Xd parameters (where X is the number of days).

5. Membership

A membership relationship exists when a user or group is a member of another group, workspace, or supported BI item. This relationship tracks organizational structure, access control, and group hierarchies.

If resource A (a user or group) is a member of resource B (a group, workspace, or supported BI item), A is said to be a member of B, and B has A as a member.

A group, workspace, or supported BI item can have zero, one, or many members—technically a many-to-many relationship. Groups can also be members of other groups, creating nested group hierarchies.

Examples of using member and group queries:

• To find all members of a specific group: has group(uri="<group-uri>")

• To find all groups that a user is a member of: has member(uri="<user-uri>")

• To find all members of a Power BI workspace: has group(uri="<workspace-uri>")

• To find all members of a Power BI report, dashboard, semantic model, app-backed report row, or dataflow: has group(uri="<powerbi-item-uri>")

Resource Types:

• user: Represents an individual user in the system. Users can be members of groups and workspaces.

• user_group: Represents a security group or organizational group. Groups can contain users and other groups as members.

• powerbi_workspace: Power BI workspaces can have users and groups as members, with role information (e.g., Admin, Member, Contributor).

• Power BI item resources: Reports, dashboards, semantic models, app-backed report rows, and dataflows can have users and groups as members when direct item access is available.

Role Information:

When querying membership relationships with extended_relationships=true, the API returns role information for Power BI workspace and item memberships when available. For example, a user might be an "Admin" or "Member" of a Power BI workspace.

Summary of Resources and Possible Relationships

Summary tables list downstream → upstream relationships: Source is the dependent resource (the one with table_dependencies or upstream_fields); Target lists its upstream dependencies. This matches has upstream(uri=...) and has upstream_fields(uri=...) in EQL. Equivalence: A is upstream of B ⇔ B has upstream A ⇔ A has downstream B.

Lineage Relationships (has upstream)

Source Resource	Relationship	Target Resource
adf_pipeline	has upstream	adf_pipeline, adf_dataflow, adf_power_query
airflow_dag	has upstream	airflow_dataset, table
airflow_task	has upstream	airflow_dataset, airflow_task, table
databricks_notebook	has upstream	table
dbt_dimension	has upstream	hex_dimension
dbt_exposure	has upstream	dbt_model, dbt_source
dbt_metric	has upstream	dbt_metric, dbt_semantic_model, dbt_model, dbt_measure, table, hex_measure
dbt_model	has upstream	dbt_model, dbt_seed, dbt_snapshot, dbt_source, dbt_metric, table
dbt_seed	has upstream	table
dbt_semantic_model	has upstream	dbt_model, dbt_source, dbt_seed, dbt_snapshot, table, hex_semantic_model
dbt_snapshot	has upstream	dbt_model, dbt_seed, dbt_snapshot, dbt_source, table
dbt_source	has upstream	table
hex_project	has upstream	table
looker_dashboard	has upstream	looker_look, looker_tile
looker_explore	has upstream	looker_explore, looker_view
looker_look	has upstream	looker_explore
looker_tile	has upstream	looker_explore
looker_view	has upstream	dbt_metric, looker_explore, looker_view, table
omni_dashboard	has upstream	omni_query
omni_model	has upstream	table
omni_query	has upstream	omni_topic, omni_view
omni_topic	has upstream	omni_view
omni_view	has upstream	table
omni_workbook	has upstream	omni_model
powerbi_app	has upstream	powerbi_report
powerbi_dashboard	has upstream	powerbi_report
powerbi_dataflow	has upstream	powerbi_dataflow
powerbi_report	has upstream	powerbi_table, powerbi_tile
powerbi_table	has upstream	powerbi_dataflow, table
powerbi_tile	has upstream	powerbi_table
salesforce_dashboard	has upstream	salesforce_report
salesforce_flow	has upstream	salesforce_field, salesforce_flow, salesforce_object
salesforce_report	has upstream	salesforce_field, salesforce_object
sigma_data_model_element	has upstream	table
sigma_workbook	has upstream	sigma_workbook_element
sigma_workbook_element	has upstream	sigma_data_model_element, sigma_workbook_element, table
snowflake_inbound_share	has upstream	snowflake_outbound_share
snowflake_semantic_view	has upstream	table
table	has upstream	dbt_metric, salesforce_object, table
tableau_custom_sql	has upstream	table
tableau_dashboard	has upstream	tableau_view
tableau_embedded_datasource	has upstream	table, tableau_custom_sql, tableau_published_datasource
tableau_published_datasource	has upstream	table, tableau_custom_sql
tableau_view	has upstream	tableau_embedded_datasource

Column-Level Lineage Relationships (has upstream_fields)

Source Field	Relationship	Target Field
column	has upstream_fields	column, salesforce_field
dbt_column	has upstream_fields	column
databricks_notebook	has upstream_fields	column
dbt_dimension	has upstream_fields	hex_dimension
dbt_metric	has upstream_fields	dbt_measure, hex_measure
hex_project	has upstream_fields	column
looker_dimension	has upstream_fields	column, looker_dimension
looker_look	has upstream_fields	looker_dimension, looker_measure
looker_measure	has upstream_fields	column, dbt_metric, looker_dimension
looker_tile	has upstream_fields	looker_dimension, looker_measure
omni_dimension	has upstream_fields	column, omni_dimension, omni_measure
omni_measure	has upstream_fields	column, omni_dimension, omni_measure
omni_query	has upstream_fields	omni_dimension, omni_measure
powerbi_column	has upstream_fields	column, powerbi_column
powerbi_measure	has upstream_fields	column, powerbi_column
powerbi_tile	has upstream_fields	powerbi_column, powerbi_measure
salesforce_field	has upstream_fields	salesforce_field
salesforce_flow	has upstream_fields	salesforce_field
salesforce_report	has upstream_fields	salesforce_field
sigma_data_model_element	has upstream_fields	column
sigma_workbook_element	has upstream_fields	column
snowflake_dimension	has upstream_fields	column
snowflake_metric	has upstream_fields	column
tableau_field	has upstream_fields	column, tableau_field
tableau_view	has upstream_fields	tableau_field

Hierarchical Relationships (has parent)

Child Resource	Relationship	Parent Resource
column	has parent	table
dbt_column	has parent	dbt_source, dbt_model, dbt_seed, dbt_snapshot
table	has parent	database_schema
database_schema	has parent	database
database	has parent	databricks_workspace, snowflake_account, sqlserver_instance
dbt_dimension, dbt_measure	has parent	dbt_model, dbt_semantic_model
dbt_seed, dbt_source, dbt_model, dbt_snapshot, dbt_exposure, dbt_metric, dbt_semantic_model	has parent	dbt_project
tableau_published_datasource, tableau_workbook	has parent	tableau_project
tableau_embedded_datasource, tableau_dashboard, tableau_view	has parent	tableau_workbook
tableau_custom_sql	has parent	tableau_embedded_datasource, tableau_published_datasource
tableau_field	has parent	tableau_embedded_datasource, tableau_published_datasource, tableau_custom_sql, tableau_view
looker_dimension, looker_measure	has parent	looker_view, looker_explore, looker_look, looker_tile
looker_view, looker_explore	has parent	looker_model
looker_model	has parent	looker_instance
looker_folder	has parent	looker_instance, looker_folder
looker_dashboard, looker_look	has parent	looker_folder
looker_tile	has parent	looker_dashboard
matillion_pipeline	has parent	matillion_project
montecarlo_monitor	has parent	montecarlo_account
powerbi_workspace	has parent	powerbi_account
powerbi_folder	has parent	powerbi_workspace
powerbi_report, powerbi_dashboard, powerbi_semantic_model, powerbi_dataflow, powerbi_app	has parent	powerbi_workspace, powerbi_folder
powerbi_table	has parent	powerbi_semantic_model
powerbi_column, powerbi_measure	has parent	powerbi_table
powerbi_column	has parent	powerbi_dataflow
powerbi_page	has parent	powerbi_report
powerbi_tile	has parent	powerbi_page
sigma_workspace, sigma_folder, sigma_data_model	has parent	sigma_account
sigma_folder	has parent	sigma_folder, sigma_workspace
sigma_workbook	has parent	sigma_folder, sigma_workspace
sigma_workbook_element	has parent	sigma_workbook
sigma_data_model_element	has parent	sigma_data_model
hex_project, hex_semantic_project	has parent	hex_workspace
databricks_notebook	has parent	databricks_workspace
snowflake_semantic_view	has parent	database_schema
hex_semantic_model	has parent	hex_semantic_project
hex_dimension, hex_measure	has parent	hex_semantic_model
snowflake_dimension, snowflake_metric	has parent	snowflake_semantic_view
snowflake_inbound_share, snowflake_outbound_share	has parent	snowflake_account
sqlserver_linked_server	has parent	sqlserver_instance
omni_folder, omni_model	has parent	omni_account
omni_folder, omni_workbook	has parent	omni_folder
omni_view, omni_topic	has parent	omni_model
omni_dimension, omni_measure	has parent	omni_view, omni_topic
omni_query, omni_dashboard, omni_view, omni_topic	has parent	omni_workbook
omni_dimension	has parent	omni_query
airflow_dag, airflow_dataset	has parent	airflow_instance
airflow_task	has parent	airflow_dag
adf_pipeline, adf_dataset, adf_dataflow, adf_power_query	has parent	adf_factory
stitch_source	has parent	stitch_account
stitch_stream	has parent	stitch_source
salesforce_folder	has parent	salesforce_org
salesforce_object	has parent	salesforce_org
salesforce_field	has parent	salesforce_object
salesforce_report, salesforce_dashboard	has parent	salesforce_org, salesforce_folder
salesforce_flow	has parent	salesforce_org

Definition Relationship (has definer)

Source Field	Relationship	Target Field
table	has definer	dbt_seed, dbt_source, dbt_model, dbt_snapshot, fivetran_connector, matillion_pipeline, databricks_notebook, adf_pipeline, adf_dataflow, adf_power_query
column	has definer	dbt_column
looker_dimension	has definer	dbt_column
looker_measure	has definer	dbt_column, dbt_metric
table	has definer	airflow_dag, airflow_task
table	has definer	stitch_stream
table	has definer	openlineage_job
database	has definer	snowflake_inbound_share, snowflake_outbound_share
salesforce_object	has definer	salesforce_flow

dbt columns vs. warehouse columns: when dbt resolves a model, source, seed, or snapshot to a physical table, each documented column is observed twice — as a dbt_column under the dbt resource (the declaration) and as a column under the table (the physical field) — connected by a defines relationship from the dbt_column to the column.

Membership Relationships (has member / has group)

Source Resource	Relationship	Target Resource
user, user_group	has member	user_group, powerbi_workspace, Power BI item resources, omni_folder
user_group, powerbi_workspace, Power BI item resources, omni_folder	has group	user, user_group

Note:

• Groups can be members of other groups, creating nested hierarchies

• Power BI workspaces can have both users and groups as members

• Power BI reports, dashboards, semantic models, app-backed report rows, and dataflows can have both users and groups as members

• Omni folders can have both users and groups as members

• Membership relationships may include role information (e.g., Admin, Member) for Power BI workspace and item memberships

• Salesforce user_group resources expose members toward observed user resources when user and group observation is enabled for the Salesforce source

Policy Regulation Relationships (has regulator / has regulated)

Source Resource	Relationship	Target Resource
powerbi_report, powerbi_dashboard, powerbi_semantic_model, powerbi_app, powerbi_dataflow	has regulator	purview_dlp_policy
purview_dlp_policy	has regulated	powerbi_report, powerbi_dashboard, powerbi_semantic_model, powerbi_app, powerbi_dataflow

Policy regulation relationships connect governed resources to the policy resources that regulate them. For Microsoft Purview, supported Power BI resources can have a purview_dlp_policy as their regulator. has regulator(x) can also be written is regulated by(x), and has regulated(x) as is regulator of(x).

Task Dependency Relationships (has upstream_task / has downstream_task)

Source Resource	Relationship	Target Resource
airflow_task	has upstream_task	airflow_task
airflow_task	has downstream_task	airflow_task

Task dependency relationships express the execution order of tasks within a pipeline (see Task-level dependencies above); they are distinct from the data lineage tables.

Usage Relationships (is user of / is used by)

Source Resource	Relationship	Target Resource
user, user_group	is user of	looker_tile, looker_explore, looker_view, looker_dimension, looker_measure, looker_look, looker_dashboard, tableau_site, tableau_dashboard, tableau_view, powerbi_account, powerbi_report, powerbi_dashboard, powerbi_semantic_model, omni_workbook, omni_dashboard, sigma_data_model_element, sigma_workbook_element, sigma_workbook, salesforce_report, salesforce_dashboard, salesforce_flow
looker_tile, looker_explore, looker_view, looker_dimension, looker_measure, looker_look, looker_dashboard, tableau_site, tableau_dashboard, tableau_view, powerbi_account, powerbi_report, powerbi_dashboard, powerbi_semantic_model, omni_workbook, omni_dashboard, sigma_data_model_element, sigma_workbook_element, sigma_workbook, salesforce_report, salesforce_dashboard, salesforce_flow	is used by	user, user_group

User-declared lineage from Custom integration

The Custom integration lets you push observations with explicit upstream dependencies. Which property to set depends on the resource type and whether the lineage is resource-level or field-level:

Resource type	Property to set	Relationship created
table	explicit_additional_dependencies	Each listed URI is upstream of the observed table
column	explicit_additional_dependencies	Each listed URI is an upstream field of the observed column
Any other type (for example view, a custom type)	table_dependencies	Each listed URI is upstream of the observed resource
Any field-like type other than column (for example dbt_metric, dbt_dimension, snowflake_metric, snowflake_dimension, looker_measure, looker_dimension, omni_measure, omni_dimension)	upstream_fields	Each listed URI is an upstream field of the observed resource

Rules: use explicit_additional_dependencies on table and column; use table_dependencies for resource-level lineage on all other types; use upstream_fields for field-level lineage on field-like resources other than column. Do not set upstream_fields directly on type: "column" — Euno recomputes it from explicit_additional_dependencies and inferred code-based column dependencies, so a value set directly on a column would be overwritten.

See the Custom Integration Properties Reference for examples.

Manually adding upstream dependencies in dbt

In addition to standard dbt-inferred relationships, Euno also supports custom dependency declarations via metadata annotations in dbt . Specifically, column-level meta fields in your .yml files can define additional upstream dependencies using the key:

euno.ai/additional_upstream_dependencies

This allows you to declare column-level relationships that are not inferable from SQL lineage. For example, create an upstream relationship from a column to a dbt metric.

Accepted formats

Both of the following are valid, add them to column definition in a .yml file:

meta:
  euno.ai/additional_upstream_depedencies:
    - metric.<metric_name>
    - model.<model_name>

meta:
  euno.ai/additional_upstream_depedencies: [metric.<metric_name>, model.<model_name>]

Supported reference types

Each value in the list should be a string referring to a valid dbt object. The following formats are supported:

Object Type	Format Example
dbt model/seed/source/snapshot	model.<dbt_project_name>.<model_name> or full unique ID
Metric (short form)	metric.<metric_name>
Metric (full unique_id)	metric.<dbt_project_name>.<metric_name>

These references will be parsed and added as additional table_dependencies in the Euno knowledge graph.