> For the complete documentation index, see [llms.txt](https://docs.euno.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.euno.ai/using-euno/impact-analysis.md).

# Impact Analysis

## Overview

The **Impact Analysis** feature helps you understand the potential consequences of modifying or removing a resource within your data environment. Rather than providing a definitive audit of what *will* break, this tool is designed to answer the question:

> **“What might be affected if I change or remove this resource?”**

This distinction is crucial. In the case of removing a specific field, the tool shows the exact resources that will break. For most other changes, it identifies everything that *might* be impacted—helping you make more informed and cautious decisions.

## When is an Impact Analysis Available?

### Supported resource types

The **Impact Analysis** button appears in the Catalog sidepane for:

* **Warehouse tables** (`table`), including views.
* **Field-level resources** — columns and BI or semantic-layer fields, including:
  * Warehouse and dbt columns: `column`, `dbt_column`
  * dbt semantic layer: `dbt_dimension`, `dbt_measure`
  * Looker: `looker_dimension`, `looker_measure`
  * Tableau: `tableau_field`, `tableau_dimension`, `tableau_measure`
  * Power BI: `powerbi_column`, `powerbi_measure`
  * Omni: `omni_dimension`, `omni_measure`
  * Cube: `cube_dimension`, `cube_measure`
  * Hex: `hex_dimension`, `hex_measure`
  * Snowflake semantic views: `snowflake_dimension`, `snowflake_metric`
  * ThoughtSpot: `thoughtspot_formula`
  * Salesforce: `salesforce_field`
  * Other field types: `table_calculation`, `custom_field`, `entity`, `metric`, `dimension`

Other resource types (for example dashboards, dbt models, or pipelines) do not show the button in the sidepane. You can still run an impact analysis on any resource URI through the AI Assistant or the `resource_impact_analysis` [MCP tool](/ai/mcp-setup.md).

### When the button is greyed out

The button is always shown for the supported types above, but it appears **greyed out** (with the tooltip *"No impacted resources found"*) when:

* the resource has no downstream dependents, or
* Euno checked for downstream impact and found none.

You can still open a greyed-out Impact Analysis; it shows a *"No downstream impact found"* empty state, and you can continue exploring lineage in the Data Model screen.

Because impact is calculated from **column-level lineage** (`upstream_fields`), resources whose integrations do not produce column-level lineage will usually show little or no field-level impact. Table-level lineage (`table_dependencies`) still contributes downstream dependents of a table, up to 13 hops.

## Triggering an Impact Analysis

To initiate an Impact Analysis:

1. Navigate to the Resource Side Panel of any supported resource.
2. Click the impact analysis button <img src="https://3442486607-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fjd87LSzdZm6uu6WlpVMg%2Fuploads%2Fgit-blob-5f2f32bb019372e7131f1c1882dd51c1d2a728cc%2Fimage.png?alt=media" alt="" data-size="line"> found in the top right hand corner of the resource's side pane.

## What Happens When an Impact Analysis is Triggered

Euno starts from an **anchor** — the field itself, or, for a table, all of the table's child columns — and combines several lineage walks into a single result set:

1. **Field consumers** — resources whose column-level lineage references the anchor, equivalent to `has upstream_fields(uri="<uri>")`. A walk that does not set a hop count includes up to 13 hops.
2. **Downstream dependents of those field consumers** — resources reached from the field consumers through table-level lineage, up to 6 hops. This is the only walk capped at 6 hops.
3. **Parents of field consumers and of that 6-hop walk** — containers of the field consumers (up to 13 hops) and containers of the resources found in the 6-hop walk (up to 3 hops).
4. **Table-level dependents** — resources that depend on the anchor itself (the field, or the table) through table-level lineage, equivalent to `has upstream(uri="<uri>")`. This walk also goes up to 13 hops. These resources are included, but their parent containers are not.

Results are deduplicated. Databases, schemas, and Databricks workspaces are excluded from the report, since they are containers rather than consumers.

**For Fields**

The anchor is the single field. The report lists the downstream fields that consume it and the resources that contain or depend on those fields.

**For Tables**

Tables are higher-level entities that contain multiple child fields. Euno anchors the analysis on all of the table's child columns at once (without listing them individually), then adds the table's own table-level dependents, up to 13 hops. This captures the complete downstream impact if the table is modified or removed.

With statement-level column dependencies enabled for SQL views, table-level `upstream_fields` can now include fields used in query logic (`JOIN`, `WHERE`, `GROUP BY`, `HAVING`, `QUALIFY`, `ORDER BY`) even when those fields are not selected in the final projection. As a result, Impact Analysis for tables may include additional downstream resources compared to projection-only lineage.

### dbt resources: analysis runs on the warehouse resource

Downstream consumers (BI fields, views, other tables) usually reference the **warehouse** table or column that a dbt resource builds, not the dbt resource itself. To give a useful result, Euno follows the dbt resource's `defines` relationship and runs the analysis on the warehouse resource it defines:

| Resource you analyze                                        | Analysis runs on                                         |
| ----------------------------------------------------------- | -------------------------------------------------------- |
| `dbt_column`                                                | the warehouse `column` it defines                        |
| `dbt_model` (including snapshots), `dbt_seed`, `dbt_source` | the warehouse `table` it defines (including its columns) |

Notes:

* If the dbt resource does not define a matching warehouse resource, or defines more than one (for example, the same model materialized in several targets), Euno does not pivot and analyzes the dbt resource directly.
* In the Catalog sidepane this applies to `dbt_column`. Model, seed, and source pivots apply when you run impact analysis on those resources through the AI Assistant or the MCP tool.
* This behavior is **specific to dbt**. Other resources that define warehouse assets (for example Azure Data Factory pipelines) are not pivoted, and BI or semantic-layer fields (for example Cube members, which use `upstream_fields` rather than `defines`) are analyzed as themselves.

## Impact Analysis Report

The report consists of two primary sections:

1. **Impacted Resources** – Resources that will be affected if the root resource is changed or removed.
2. **Impacted Users** – Downstream users who may be affected (e.g., "David Smith," who created a dashboard that uses the impacted field).

### Impacted Resources

After running the query, you’ll see an aggregated summary such as:

> **"Changing this resource will affect:"**\
> • 26 Dashboards\
> • 783 Views\
> • 32 Data Sources\
> • 32 Snowflake Views\
> • 12 dbt Models\
> • 6 Tables

This provides a high-level snapshot of what may be at risk.

#### **Exploring the Results**

* A search bar allows you to filter results by name.
* **Download CSV** exports the full list of impacted resources.
* Resources are grouped by type, and each group can be expanded to reveal details:
  * Click a category (e.g., “dbt Models” or “Dashboards”) to see specific impacted items.
  * For fields, the report shows their parent resource (e.g., a dbt model, table, or data source).
  * Expand each parent to view the exact fields that are affected.

This layered structure allows you to drill down and understand exactly which components are vulnerable to the change.

### **Impacted Owners**

The second section of the report highlights who may be affected downstream:

* This view identifies BI owners who might be impacted, based on usage metrics from the BI platform.
* For each user, you will see summarized engagement data such as:

  > **"732 impressions on 6 dashboards, 21 views, and 4 data sources"**
* This is determined by evaluating all resources in the critical downstream path of the changed resource.

#### **Exploring the Results**

The Impacted Owners View is organized into a clear, logical hierarchy, starting from the right-most (most downstream) resource and tracing back to the root resource:

```
Dashboard (123 impressions)
└── Field X in Data Source Y
    ├── Used in View 1
    └── Used in View 2
```

This structure helps you understand not only who is affected, but also ho&#x77;**,** from top-level dashboards down to the specific fields and views involved.

The list is sorted by impressions/queries, ensuring that the most critical areas of impact appear first. The section is searchable by user name, allowing for quick identification of affected users. Each user entry includes a redirect icon that opens their context directly in the Data Model screen for deeper analysis.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.euno.ai/using-euno/impact-analysis.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
