topic Re: Dashboard DAB Deployment: default_catalog and default_schema do not work for metric views anymor in Warehousing & Analytics

Dashboard DAB Deployment: default_catalog and default_schema do not work for metric views anymore

Capri — Wed, 30 Sep 2026 08:13:49 GMT

We deploy Dashboards using DAB. We set default_catalog and default_schema for the dashboard, so in the `dashboard.lvdash.json` we only need the last part of table and metric names. Starting yesterday (Sep 29th, 2026), this does not work anymore and we get the following API error:

Error: cannot create resources.dashboards.test_dashboard: validation failed: [[dashboard.datasets[f9427c6f].asset_name] invalid asset name [asset_name = test_metric_view]] (400 INVALID_PARAMETER_VALUE) Endpoint: POST https://adb-<workspace_id>.azuredatabricks.net/api/2.0/lakeview/dashboards?dataset_catalog=<catalog_name>&dataset_schema=<schema_name> HTTP Status: 400 Bad Request API error_code: INVALID_PARAMETER_VALUE API message: validation failed: [[dashboard.datasets[f9427c6f].asset_name] invalid asset name [asset_name = test_metric_view]]

We have experienced this in at least 3 separate projects and cannot link the error to any changes on our end.

Minimal example to reproduce:
`dashboard.lvdash.json`:

{ "datasets": [ { "name": "f9427c6f", "displayName": "test_metric_view", # BUG: Short name instead of <catalog_name>.<schema_name>.test_metric_view "asset_name": "test_metric_view" } ], "pages": [ { "name": "c9748f1d", "displayName": "Test Page", "layout": [ { "widget": { "name": "3bdaafb0", "queries": [ { "name": "main_query", "query": { "datasetName": "f9427c6f", "fields": [ {"name": "id", "expression": "`id`"}, {"name": "name", "expression": "`name`"} ], "disaggregated": True } } ], "spec": { "version": 3, "widgetType": "bar", "encodings": { "x": {"fieldName": "id", "scale": {"type": "quantitative"}}, "y": {"fieldName": "name", "scale": {"type": "categorical"}} }, "data": {"queryName": "main_query"} } }, "position": {"x": 0, "y": 0, "width": 6, "height": 6} } ], "pageType": "PAGE_TYPE_CANVAS", "layoutVersion": "GRID_V1" } ] }

dashboard.yml:

resources: dashboards: test_dashboard: display_name: "Bug Repro - Metric View Short Name" file_path: ../dashboard.lvdash.json warehouse_id: ${var.warehouse_id} dataset_catalog: <catalog_name> dataset_schema: <schema_name>

The error occured within serverless environment version 5 and with the most recent Databricks CLI v1.18.0.

Re: Dashboard DAB Deployment: default_catalog and default_schema do not work for metric views anymor

Satyasai — Wed, 30 Sep 2026 10:39:42 GMT

This error occurs due to a recent update in strict validation enforcement in the Databricks Lakeview/Dashboard backend REST API (/api/2.0/lakeview/dashboards).

In the past, when passing dataset_catalog and dataset_schema via the query parameters, the backend allowed datasets inside .lvdash.json to specify a simple identifier (e.g., "test_metric_view") for asset_name and implicitly prepend the default catalog and schema.

Databricks has tightened the backend validation such that asset_name must always be a fully qualified 3-level Unity Catalog identifier (..), independent of whether dataset_catalog or dataset_schema are passed in the API call or DAB resource definition.

Recommended Fixes

Fix 1: Explicitly Fully-Qualify asset_name in the JSON File

Update the asset_name field in your dashboard.lvdash.json to explicitly use the full 3-level name:

JSON

{

"datasets": [

{

"name": "f9427c6f",

"displayName": "test_metric_view",

"asset_name": "<catalog_name>.<schema_name>.test_metric_view"

}

]

}

Fix 2: Parameterize catalog/schema using DAB Variables

If your bundle is deploying across multiple environments (e.g., dev, staging, prod) and uses dataset_catalog/dataset_schema to dynamically select environments, inject DAB variables into your JSON definition or convert it to a .json.tmpl file.

Option A: Using Databricks Asset Bundle Template variables (.tmpl)

Rename dashboard.lvdash.json to dashboard.lvdash.json.tmpl and reference your bundle variables directly:

JSON

{

"datasets": [

{

"name": "f9427c6f",

"displayName": "test_metric_view",

"asset_name": "${var.catalog_name}.${var.schema_name}.test_metric_view"

}

]

}

In databricks.yml:

YAML

resources:

dashboards:

test_dashboard:

display_name: "Bug Repro - Metric View Short Name"

file_path: ../dashboard.lvdash.json.tmpl

warehouse_id: ${var.warehouse_id}

targets:

dev:

variables:

catalog_name: dev_catalog

schema_name: dev_schema

prod:

variables:

catalog_name: prod_catalog

schema_name: prod_schema

Re: Dashboard DAB Deployment: default_catalog and default_schema do not work for metric views anymor

Capri — Wed, 30 Sep 2026 11:48:59 GMT

Thank you very much for the reply!

Fix 1 would work, but hard coding the catalog and schema name would not be a good solution for us, as we need different catalog names for dev and prod target.

Fix 2 would be great, but I cannot make it work, yet. I applied the changes as recommended and run `databricks bundle deploy`, but get the following error:

Error: invalid dependency "${var.catalog_name}", no such node ""

Re: Dashboard DAB Deployment: default_catalog and default_schema do not work for metric views anymor

Louis_Frolio — Fri, 02 Oct 2026 17:10:38 GMT

Hello @Capri, I took a look at both internal and external documentation and here is what I found.

You're not alone, and nothing on your side caused this. @SamuelHarris reported the identical failure on Sep 30 on this thread (https://community.databricks.com/t5/warehousing-analytics/recommended-local-development-workflow-for-dashboard-ci-cd-with/td-p/156465), same invalid asset name 400 and the same invalid dependency "${var.catalog}" error when he tried the variable workaround. The failing call is the server side POST /api/2.0/lakeview/dashboards, so your CLI version isn't the culprit. Something changed in the Lakeview API's validation on or around Sep 29.

The pattern you're using is the documented one. The bundle docs describe dataset_catalog and dataset_schema as the defaults for every dataset in the dashboard unless the query says otherwise, and in May a Databricks employee (stbjelcevic) confirmed on that other thread that the deploy-target .lvdash.json should hold unqualified asset_name values and that there's no way to parameterize asset_name inside the JSON body. So the API is now rejecting a shape the docs still call valid. I can't tell from public documentation whether that's intentional or a regression, so please open a support ticket with your minimal repro, CLI version, cloud, the exact bundle deploy output, and links to both threads. An issue on the CLI repo wouldn't hurt either, since that team owns the dataset_catalog/dataset_schema fields on the bundle side.

Credit to @Satyasai for the diagnosis: validation on asset_name got stricter, and Fix 1 (fully qualify it) does work. Fix 2 is where I'd steer you differently. The .tmpl convention is only processed by databricks bundle init when it scaffolds a new project, using Go template syntax. At bundle deploy the CLI reads your .lvdash.json as-is and ships it to the API as serialized_dashboard. Bundle variable substitution covers the YAML, not that JSON body, so when the CLI spots ${var.catalog_name} in there it treats it as a reference it can't resolve, and that's your no such node "" error. Your variables belong in the resource YAML, which is what you already have. One side note for anyone copying the published dashboard example: it declares catalog_name/schema_name but references ${var.catalog}/${var.schema} in the resource block. Those names have to match.

What works today while keeping dev and prod separate: render the JSON in your pipeline before deploy, which is the pattern stbjelcevic recommended in May even before the breakage.

# dashboard.template.json contains: "asset_name": "__CATALOG__.__SCHEMA__.test_metric_view"
sed -e "s/__CATALOG__/${CATALOG}/g" -e "s/__SCHEMA__/${SCHEMA}/g" \
    dashboard.template.json > dashboard.lvdash.json
databricks bundle deploy -t prod

(Those are plain shell variables from your pipeline, not bundle variables.) If you'd rather stay pure bundle, keep one fully qualified JSON per environment and override file_path in each target; it costs you duplicated JSON but skips the transform step. Either way, keep dataset_catalog and dataset_schema on the resource for SQL-based datasets, since the new validation only fires on asset_name.

If you need something in place right now and don't need the native metric view dataset experience, a stopgap is a SQL dataset against the metric view, something like SELECT dim, MEASURE(my_measure) FROM test_metric_view GROUP BY dim. SQL datasets resolve through the defaults at query time rather than being validated at create time. I haven't tested that against the new validation, so treat it as a lead rather than a guarantee.

At the end of the day, the transform step is a few lines of shell and was the recommended workflow anyway, so I'd lean on that and let the ticket run its course.

References

Related thread with the May confirmation and the Sep 30 report: https://community.databricks.com/t5/warehousing-analytics/recommended-local-development-workflow-for-dashboard-ci-cd-with/td-p/156465
Bundle dashboard resource fields: https://docs.databricks.com/aws/en/dev-tools/bundles/resources
Bundle example for dashboard catalog and schema parameterization: https://docs.databricks.com/aws/en/dev-tools/bundles/examples
Bundle variables and substitutions: https://docs.databricks.com/aws/en/dev-tools/bundles/variables
Bundle templates (.tmpl and bundle init😞 https://docs.databricks.com/aws/en/dev-tools/bundles/templates
Lakeview create dashboard API (dataset_catalog/dataset_schema😞 https://docs.databricks.com/api/lakeview/v1/create-dashboard
Databricks CLI issues: https://github.com/databricks/cli/issues

Regards, Louis.