> 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/sources/analytics-notebooks/hex-technologies/hex-integration-discovered-resources.md). # Hex Integration Discovered Resources ## Overview The Hex Technologies integration discovers the configured Hex workspace, the projects in it, and the users who own or created those projects. It discovers the following resources: * Hex workspace (`hex_workspace`) * Hex project (`hex_project`) * User (`user`) Hex resources use the URI prefix `hex`. Project lineage and warehouse usage are not read from the Hex API; they come from your warehouse integration's query history (see [Lineage](#lineage)). ## Resource hierarchy ``` Hex Workspace └── Hex Project ``` ## Hex workspace (`hex_workspace`) A single Hex workspace, observed for each configured Hex source. | Property | Type | Description | | --------- | ------ | --------------------------------------------------- | | `name` | string | The name of the Hex workspace (from configuration). | | `type` | string | Always `hex_workspace`. | | `subtype` | string | Always `hex_workspace`. | **URI pattern** ``` hex.workspace. ``` Example: `hex.workspace.5b1f9a2c-7d3e-4c1a-9e8b-2f6d0c4a7e11` ## Hex project (`hex_project`) A Hex project, the main analytical resource in Hex, containing notebooks, data applications, and other analytical content. | Property | Type | Description | | ------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `name` | string | The title of the Hex project. | | `type` | string | Always `hex_project`. | | `subtype` | string | Always `hex_project`. | | `description` | string | The description of the project, if provided. | | `native_id` | string | The unique project ID in Hex. | | `created_at` | timestamp | When the project was created. | | `updated_at` | timestamp | When the project was last edited. | | `created_by` | string | The email address of the user who created the project. | | `owner` | string | The email address of the owner of the Hex project. Derived from the project owner in Hex. | | `is_active` | boolean | `true` when the project is active (not trashed). | | `is_published` | boolean | Indicates whether the Hex project has been published as an app. | | `last_published_at` | timestamp | Date of the most recent edit to the published project. | | `native_last_data_update` | timestamp | Date of the most recent data refresh of the published app. | | `last_viewed_at` | string | ISO 8601 timestamp of when the project was last viewed. | | `total_impressions_14d` | number | Total app views over the past 14 days. This property is only available for published Hex projects. | | `total_impressions_30d` | number | Total app views over the past 30 days. This property is only available for published Hex projects. | | `total_impressions_60d` | number | Total app views over the past 60 days. Derived by combining the current 30-day count with the 30-day count recorded at least 30 days earlier; empty until Euno has 30 days of history for the project. | | `tags` | list | All the Hex Categories associated with the project. See [Hex Documentation](https://learn.hex.tech/docs/organize-content/statuses-categories#categories). | | `collection` | list | The names of the Hex Collections the project belongs to. | | `meta` | object | `meta.status` holds the project status, if available (see [Hex Documentation](https://learn.hex.tech/docs/organize-content/statuses-categories#statuses)). When the status is `Endorsed`, `meta.bi_certified` is set to `certified`. | | `external_links` | list | An **Open in Hex** link to the project. | **URI pattern** ``` hex.project. ``` Example: `hex.project.0f3c8e21-6a4b-4d9e-b1c7-83a5e2d9f604` ### Usage analytics The Hex integration captures usage analytics for projects: * **App views**: How often projects are viewed as applications (`total_impressions_*`). * **Time-based metrics**: Separate tracking for 14-day, 30-day, and 60-day periods. * **Last activity**: When the project was most recently viewed (`last_viewed_at`). ### Project organization Projects are organized with the following structure: * **Workspace level**: All projects belong to their parent workspace. * **Categorization**: Projects can be tagged with categories (`tags`) and grouped in collections (`collection`). * **Status tracking**: Projects have status information, if available (`meta.status`). * **Ownership**: Attribution to the creating (`created_by`) and owning (`owner`) users. ## User (`user`) A Hex user who owns or created at least one project, identified by email address. These observations are non-authoritative and are merged with the same user discovered by other integrations. | Property | Type | Description | | --------------- | ------ | ------------------------- | | `name` | string | The user's email address. | | `type` | string | Always `user`. | | `email_address` | string | The user's email address. | **URI pattern** ``` user_account. ``` Example: `user_account.jane.doe_at_acme.com` ## Relationships Each row is one relationship edge, written in the canonical direction for its family. Use the predicate in each heading to search for these relationships in EQL. ### Containment (`has parent` / `has child`) | Source type | Relationship | Target type | Notes | | ------------- | ------------ | --------------- | ----- | | `hex_project` | has parent | `hex_workspace` | | ### Lineage (`has upstream` / `has downstream`) | Source type | Relationship | Target type | Notes | | ------------- | ------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------ | | `hex_project` | has upstream | `table` | Warehouse tables the project's SQL cells read. Resolved from Hex-tagged queries in Snowflake and BigQuery query history. | ### Field-level lineage (`has upstream_fields` / `has downstream_fields`) | Source type | Relationship | Target type | Notes | | ------------- | -------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------- | | `hex_project` | has upstream\_fields | `column` | Warehouse columns the project's SQL cells read. Resolved from Hex-tagged queries in Snowflake and BigQuery query history. | ### Usage (`is user of` / `is used by`) | Source type | Relationship | Target type | Notes | | ----------- | ------------ | ------------- | --------------------------------------------------------------------------------------------------------------------------- | | `user` | is user of | `hex_project` | Users who ran the project's queries. Resolved from Hex-tagged queries in Snowflake, BigQuery, and Databricks query history. | ## Lineage Hex queries are distinguishable in the data warehouse's query history. See [Hex Documentation](https://learn.hex.tech/docs/explore-data/cells/sql-cells/sql-cells-introduction#query-metadata) for how Hex tags each query with metadata about the originating project and user. Euno leverages Hex's query metadata feature to build the lineage and usage information about Hex projects. See the relevant parts in each warehouse integration documentation. ## Usage in EQL ``` # Hex projects that read a given warehouse table type = 'hex_project' AND has upstream(uri = '') # Published Hex projects with no app views in the last 30 days type = 'hex_project' AND is_published is true AND total_impressions_30d = 0 # Users who ran queries from a given Hex project type = 'user' AND is user of(uri = '') ``` ## Known limitations Due to current Hex API constraints, the completeness of extracted metadata is affected. Lineage in Euno is derived from warehouse query history. Snowflake and BigQuery sources include Hex queries from the last 7 days by default. That lookback is a setting on the warehouse source, not a fixed limit. As a result: * **Delayed updates**: If a project is modified in a way that changes its lineage, it may take time for Euno to reflect these changes. During this period, the old and new lineage may appear overlapped. * **Missing lineage for inactive projects**: If a project has not been executed within the configured lookback, and no queries are available, Euno will be unable to detect or display its lineage. --- # 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/sources/analytics-notebooks/hex-technologies/hex-integration-discovered-resources.md?ask=&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.