From 62c42927d0e615ee1efd119b1c2ebc0fa9adfb6d Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:09:00 -0400 Subject: [PATCH 01/12] docs(explore): list value label positions and that they're set per series Fixes #1533 --- explore/configure-charts.mdx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/explore/configure-charts.mdx b/explore/configure-charts.mdx index b620169af..67d3fa760 100644 --- a/explore/configure-charts.mdx +++ b/explore/configure-charts.mdx @@ -34,6 +34,12 @@ The options available in here will depend on the data in your chart. But, in her - Show value labels or group totals on data points - Hide a series from your chart +### Value label position + +Use the **Value labels** dropdown on a series to choose where its labels sit: **Hidden**, **Top**, **Bottom**, **Left**, **Right**, or **Inside**. **Hidden** turns the labels off. + +The position is set per series, so different series on the same chart can use different positions. For a grouped series, the dropdown on the group sets every series in it, and shows **Mixed** when the series in the group use different positions. Expand the group to set the position of one series. + ### Value label colors When you show value labels on bar, line, area, or pie charts, Lightdash chooses a label color automatically: From 53ffd510e98d887436b9100edc10b3d264abe11e Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:09:27 -0400 Subject: [PATCH 02/12] docs(agents): the Insights dashboard on Threads is limited to organization admins Fixes #1423 --- agents/visibility.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/agents/visibility.mdx b/agents/visibility.mdx index 127cc53f7..0a6a1bffe 100644 --- a/agents/visibility.mdx +++ b/agents/visibility.mdx @@ -37,6 +37,8 @@ Every agent conversation, in the Lightdash app or Slack, is visible to admins un /> +To see usage across the whole organization, select **Insights** on the **Threads** page. It opens the **AI Agents Insights** dashboard, which summarizes AI agent usage for your organization. Only organization admins can open Insights. Admins who see **Threads** for the projects they manage can't open it. + ## MCP activity The **MCP → Analytics** page covers both directions of MCP activity: external assistants calling tools on the [Lightdash MCP server](/agents/lightdash-mcp), and Lightdash agents calling tools on [connected external MCP servers](/agents/connect-external-mcp-servers). Admins can see what was called, by whom, and whether it succeeded. From 6d1de94384ab1373c1c89dfb775b0e9c99f96c61 Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:10:15 -0400 Subject: [PATCH 03/12] docs(integrations): joins across dbt sources on BigQuery need datasets in one location Fixes #1445 --- integrations/connect-project.mdx | 2 ++ integrations/dbt/projects.mdx | 2 ++ 2 files changed, 4 insertions(+) diff --git a/integrations/connect-project.mdx b/integrations/connect-project.mdx index b0e6432a2..5a7f6ea57 100644 --- a/integrations/connect-project.mdx +++ b/integrations/connect-project.mdx @@ -204,6 +204,8 @@ The data location of the dataset in BigQuery where the output of your dbt models You can find the location of the dataset you're using for your dbt project [in your dbt profiles.yml file](https://docs.getdbt.com/reference/warehouse-profiles/bigquery-profile#dataset-locations), or in your BigQuery console. +Every query from this connection runs in this location. If you connect [multiple dbt sources](/integrations/dbt/projects#connecting-multiple-dbt-sources), their datasets need to be in the same location for joins between them to work. + A BigQuery Data set info panel with the Data location row reading US diff --git a/integrations/dbt/projects.mdx b/integrations/dbt/projects.mdx index 9adac5eb4..e284b3ff3 100644 --- a/integrations/dbt/projects.mdx +++ b/integrations/dbt/projects.mdx @@ -267,6 +267,8 @@ All sources are compiled together into one set of Explores, so tables from diffe All sources share the Lightdash project's warehouse connection. On a project with [multiple warehouse connections](/workspace-admin/multiple-warehouse-connections), you can run an additional source on another connection. +On BigQuery, a connection runs every query in the [location set on the connection](/integrations/connect-project#bigquery), and one query can't read datasets from different locations. Joins between models from different sources only work when their datasets are in the same location. + ### Adding and managing sources Go to **Project settings → dbt connection**. When the feature is enabled for your org, you'll see a **dbt sources** panel that lists the primary source plus any additional ones. Each row shows the source's display name and its git identity (`repository · branch · subfolder`), or the connection type for non-git sources. From 8bc8778ebc7a6aa60b67c6a03da5060bfdfdadd4 Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:10:30 -0400 Subject: [PATCH 04/12] docs(integrations): document the required BigQuery Data set field Fixes #1494 --- integrations/connect-project.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/integrations/connect-project.mdx b/integrations/connect-project.mdx index 5a7f6ea57..ab06a358d 100644 --- a/integrations/connect-project.mdx +++ b/integrations/connect-project.mdx @@ -196,6 +196,10 @@ Google rejected the BigQuery credentials (invalid_grant: …). Create a new JSON key for the service account and upload it in the project's Warehouse Connection settings. An error that says Google rejected the BigQuery *refresh token* comes from a **Sign in with Google** connection instead; see **BigQuery tokens expiring** above. +##### Data set + +This is the name of your dbt dataset: the BigQuery dataset where the output of your dbt models is written to. It's required, and it must match the `dataset` value in your dbt `profiles.yml` file. When you pick a data set from the list, Lightdash fills in its **Location** for you. + ##### Location The data location of the dataset in BigQuery where the output of your dbt models is written to. From f32bf5764401f7412e1cd62fb26bab62a8ce0a04 Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:10:47 -0400 Subject: [PATCH 05/12] docs(workspace-admin): the export truncation notice is a short-lived toast Fixes #1496 --- workspace-admin/export-limits.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/workspace-admin/export-limits.mdx b/workspace-admin/export-limits.mdx index dfa660ae3..26efe500d 100644 --- a/workspace-admin/export-limits.mdx +++ b/workspace-admin/export-limits.mdx @@ -51,7 +51,7 @@ Changes take effect immediately for new queries and exports. Existing scheduled | Surface | Behavior | | --- | --- | | Explorer and SQL runner row-limit selector | Maximum value is clamped to the org's effective query row limit. | -| CSV and Excel downloads from charts, dashboards, and underlying data | Truncated to the org's effective cell limit, with a banner shown when truncation happens. | +| CSV and Excel downloads from charts, dashboards, and underlying data | Truncated to the org's effective cell limit. When truncation happens, a warning notification, **The results in this export have been limited.**, shows for about 5 seconds and then closes. | | Scheduled deliveries (CSV, Excel) | Use the org's effective cell limit at run time. | | Google Sheets Sync (recurring chart sync) | Bounded by the org's effective query row limit, not the cell limit. The sync runs the chart's saved query as-is and fails, rather than truncating, if that query's row limit is above the ceiling. | | API responses for `/api/v1/org/settings` | Return the resolved effective values, falling back to the instance defaults when no override is set. | From 1de9e308f9d49366bd42e8f9ef5d9b57c42da49c Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:11:03 -0400 Subject: [PATCH 06/12] docs(support): show where admins enable user impersonation for every deployment Fixes #1486 --- support/support-access.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/support/support-access.mdx b/support/support-access.mdx index 5f6cd3490..f5cbd12a6 100644 --- a/support/support-access.mdx +++ b/support/support-access.mdx @@ -27,14 +27,15 @@ When a user is impersonated: Impersonation by organization admins is behind a feature flag. On Lightdash Cloud, [contact support](mailto:support@lightdash.com) to enable it for your organization. Self-hosted instances enable it themselves, as described below. -Only **organization admins** can impersonate other users, and only users inside their own organization. Once the feature is available, admins enable it from the organization settings and can turn it off at any time. +Only **organization admins** can impersonate other users, and only users inside their own organization. Once the feature is available, an organization admin goes to **Settings** → **General** (under **Organization settings**) and turns on **Enable user impersonation** in the **User impersonation** section. Turn it off there at any time. **Self-hosted instances** turn on the feature flag themselves: 1. Add `user-impersonation` to the `LIGHTDASH_ENABLE_FEATURE_FLAGS` environment variable. The value is a comma-separated list of flag IDs, so if you already set it, append the ID, for example `LIGHTDASH_ENABLE_FEATURE_FLAGS=embedding,user-impersonation`. See [feature flags](/self-host/customize-deployment/environment-variables#feature-flags). 2. Restart Lightdash so the new value takes effect. - 3. An organization admin goes to **Settings** → **General** (under **Organization settings**) and turns on **Enable user impersonation** in the **User impersonation** section. + + An organization admin then enables impersonation in the organization settings, as described above. From eeb0375285a0c743c84b0c5c4cfe4505e7693619 Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:11:07 -0400 Subject: [PATCH 07/12] docs(workspace-admin): app_uuid is self-reported by the originating data app Fixes #1490 --- workspace-admin/usage-analytics.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/workspace-admin/usage-analytics.mdx b/workspace-admin/usage-analytics.mdx index 508afb467..81b2fcf33 100644 --- a/workspace-admin/usage-analytics.mdx +++ b/workspace-admin/usage-analytics.mdx @@ -75,7 +75,7 @@ The following query tags are sent: | scheduler_uuid | Scheduler unique identifier. Only set when the query is triggered by a scheduled delivery, alert, or Google Sheets sync. | | scheduler_name | Human-readable name of the scheduler. Only set when the query is triggered by a scheduler. | | job_id | Scheduler job identifier for a single run of a scheduler. Only set when the query is triggered by a scheduler. | -| app_uuid | [Data app](/data-apps) unique identifier. Lightdash sets it automatically when the query originates from a running data app. | +| app_uuid | [Data app](/data-apps) unique identifier. Lightdash sets it automatically when the query originates from a running data app. The value is reported by the app itself in a request header and isn't verified by the server, so treat it as a best-effort attribution signal for usage reports. | | query_context | Which context the query was executed in. See [Query contexts](#query-contexts) below for the full list of values. | | agent | `true` when an AI agent ran the query. Set with [agent identity](/agents/agent-identity#find-agent-queries-in-the-warehouse). | | agent_surface | Where the AI agent ran, for example `mcp` or `slack_agent`. Only set with [agent identity](/agents/agent-identity#find-agent-queries-in-the-warehouse). | From 395ac529ee5f544b0b4d3423985ead362acb0a1c Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:11:31 -0400 Subject: [PATCH 08/12] docs(workspace-admin): document the view:Learn custom-role scope Fixes #1493 --- explore/learn.mdx | 2 +- workspace-admin/custom-roles.mdx | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/explore/learn.mdx b/explore/learn.mdx index 6300d4894..d67764e2d 100644 --- a/explore/learn.mdx +++ b/explore/learn.mdx @@ -14,7 +14,7 @@ Learn is a library of guided walkthroughs inside Lightdash. Each walkthrough tea Click the **Learn** icon (a graduation cap) in the top bar, beside notifications and help. The library opens with the walkthroughs available to you. -The first time anyone in your organization opens Learn, it asks for an organization admin to enable it. Once an admin has, every walkthrough is open to everyone in the organization. +The first time anyone in your organization opens Learn, it asks for an organization admin to enable it. Once an admin has, every walkthrough is open to everyone in the organization who has access to Learn. Every built-in organization role has access; on a custom organization role, access needs the [`view:Learn` scope](/workspace-admin/custom-roles#learn-scope). ## Enable Learn for your organization diff --git a/workspace-admin/custom-roles.mdx b/workspace-admin/custom-roles.mdx index 994d5e2b9..8bb12e3c3 100644 --- a/workspace-admin/custom-roles.mdx +++ b/workspace-admin/custom-roles.mdx @@ -404,6 +404,10 @@ Two scopes decide what someone sees under **Ask AI** in the settings: - **`manage:AiAgent`** is a project scope. It shows the Ask AI section, such as **Threads** and **Agents**, with data limited to the projects where the role applies. - **`manage:OrganizationAiAgent`** (description: *Configure organization AI settings*) is an organization-only scope, so add it to an organization-level custom role. It adds **Ask AI** → **General** and covers every project. Organization Developers and Admins hold it. +### Learn scope + +The `view:Learn` scope (description: *View and use Learn walkthroughs*), in the **Organization Management** group, controls who can see and open [Learn](/explore/learn). Every built-in organization role includes it. Users whose organization role is a custom role only see Learn if that role includes `view:Learn`, so you can roll Learn out to some roles first. Adding the scope to a project-level custom role doesn't grant access. + ### SQL-related scopes Three scopes control different SQL-authoring features. They are independent — granting one does not grant the others. From 5445400ed2a5a32163905c8dbcd0e86439d3634b Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:12:28 -0400 Subject: [PATCH 09/12] docs(embed): the React SDK filters prop replaces saved filters and re-matches tiles by field Fixes #1485 --- embed/react-sdk.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/embed/react-sdk.mdx b/embed/react-sdk.mdx index bdc97144e..333d9a522 100644 --- a/embed/react-sdk.mdx +++ b/embed/react-sdk.mdx @@ -1460,6 +1460,10 @@ Pass the `paletteUuid` prop to the `Lightdash.Dashboard` component: Filters can be passed to `` to filter dimensions by values. Filters are applied as AND operations, each further restricting results. The Chart and Explore components do not support the `filters` prop. +When you pass `filters`, they replace the dashboard's saved dimension filters for that embed instead of adding to them. [Locked](/explore/dashboards/filter#locking-dashboard-filters) saved filters are the exception: they stay applied, and an SDK filter on a locked field is ignored. + +Each SDK filter applies to every tile that has a field with the same name and type as the `model` and `field` you pass. Any per-tile targets set on the dashboard filter's **Tiles** (or **Tabs & tiles**) tab aren't used. A tile with no matching field isn't filtered. + For the `filters` prop to work, your JWT must have `dashboardFiltersInteractivity` set to `enabled: 'all'`. Without this configuration, filters will not be applied. From ae85df7cf59da1a1f1cb3d684939d0572a85ccd2 Mon Sep 17 00:00:00 2001 From: Tori Whaley <115008152+torimwhaley@users.noreply.github.com> Date: Thu, 22 Oct 2026 18:13:27 -0400 Subject: [PATCH 10/12] docs(self-host): correct where admins manage custom roles Fixes #1503 --- self-host/enterprise-features.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/self-host/enterprise-features.mdx b/self-host/enterprise-features.mdx index c1c5d8c5e..e13cf6e72 100644 --- a/self-host/enterprise-features.mdx +++ b/self-host/enterprise-features.mdx @@ -125,7 +125,7 @@ LIGHTDASH_IFRAME_EMBEDDING_DOMAINS=https://app.example.com,https://reports.examp CUSTOM_ROLES_ENABLED=true ``` -Restart the backend. Admins can then build and assign roles from **Organization settings → Roles**. +Restart the backend. Organization admins can then build and assign roles from **Settings** → **Custom roles** (under **Organization settings**). ### Service accounts From ab53be58587584b953de2c8d8f04247762558daf Mon Sep 17 00:00:00 2001 From: "Codex (winnie)" <91998347+gwenwindflower@users.noreply.github.com> Date: Thu, 29 Oct 2026 13:29:33 -0500 Subject: [PATCH 11/12] docs(embed): clarify how SDK filters combine Co-Authored-By: Codex --- embed/react-sdk.mdx | 2 +- integrations/dbt/projects.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/embed/react-sdk.mdx b/embed/react-sdk.mdx index 333d9a522..5a97eb4d6 100644 --- a/embed/react-sdk.mdx +++ b/embed/react-sdk.mdx @@ -1458,7 +1458,7 @@ Pass the `paletteUuid` prop to the `Lightdash.Dashboard` component: ## Filtering data -Filters can be passed to `` to filter dimensions by values. Filters are applied as AND operations, each further restricting results. The Chart and Explore components do not support the `filters` prop. +Pass `filters` to `` to filter dimensions by value. The filters in this prop combine with AND. The Chart and Explore components do not support the `filters` prop. When you pass `filters`, they replace the dashboard's saved dimension filters for that embed instead of adding to them. [Locked](/explore/dashboards/filter#locking-dashboard-filters) saved filters are the exception: they stay applied, and an SDK filter on a locked field is ignored. diff --git a/integrations/dbt/projects.mdx b/integrations/dbt/projects.mdx index e284b3ff3..6ebed7469 100644 --- a/integrations/dbt/projects.mdx +++ b/integrations/dbt/projects.mdx @@ -267,7 +267,7 @@ All sources are compiled together into one set of Explores, so tables from diffe All sources share the Lightdash project's warehouse connection. On a project with [multiple warehouse connections](/workspace-admin/multiple-warehouse-connections), you can run an additional source on another connection. -On BigQuery, a connection runs every query in the [location set on the connection](/integrations/connect-project#bigquery), and one query can't read datasets from different locations. Joins between models from different sources only work when their datasets are in the same location. +For BigQuery joins across sources, check the connection's [dataset location requirements](/integrations/connect-project#location). ### Adding and managing sources From 3e85cf3c1bb8e082645c7950bd01191c4edbc6fd Mon Sep 17 00:00:00 2001 From: "Codex (winnie)" <91998347+gwenwindflower@users.noreply.github.com> Date: Thu, 29 Oct 2026 13:31:38 -0500 Subject: [PATCH 12/12] docs(dbt): link to the BigQuery connection section Co-Authored-By: Codex --- integrations/dbt/projects.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/integrations/dbt/projects.mdx b/integrations/dbt/projects.mdx index 6ebed7469..535ce040d 100644 --- a/integrations/dbt/projects.mdx +++ b/integrations/dbt/projects.mdx @@ -267,7 +267,7 @@ All sources are compiled together into one set of Explores, so tables from diffe All sources share the Lightdash project's warehouse connection. On a project with [multiple warehouse connections](/workspace-admin/multiple-warehouse-connections), you can run an additional source on another connection. -For BigQuery joins across sources, check the connection's [dataset location requirements](/integrations/connect-project#location). +For BigQuery joins across sources, check the [dataset location requirements](/integrations/connect-project#bigquery) in the connection settings. ### Adding and managing sources