hi @playnicekids ,

You've hit a known dev-UX gap. dataset_catalog and dataset_schema on the dashboard resource are the intended parameterization mechanism, but they only resolve at bundle deploy time, which is why workspace editing of an unqualified JSON fails with TABLE_OR_VIEW_NOT_FOUND.

Quick answers to your four:

1. Yes. The deploy-target .lvdash.json should hold unqualified asset_name values and is only expected to resolve after bundle deploy.
2. Effectively yes. Direct workspace editing of the unqualified file isn't reliable. Treat it as generated output and mark it "do not hand-edit."
3. Not an anti-pattern. Maintaining a dev-qualified JSON in source and transforming it during CI is the recommended workflow today.
4. No way to parameterize asset_name inside the JSON body. dataset_catalog / dataset_schema at the bundle resource level are the only knobs.

Two patterns that work in practice:

• Two-file: keep my_dashboard.dev.lvdash.json (dev-qualified, what developers iterate on in the workspace) and generate my_dashboard.lvdash.json (unqualified, deploy-target) in CI before bundle deploy. Simple, clear ownership.
• Programmatic: load a template JSON, inject catalog/schema per environment, and publish via the Lakeview SDK (link) (lakeview.create / lakeview.publish). The bundle just orchestrates a notebook. More control, less reliance on file-naming convention.

If you want pure-bundle with no transform step, you can run a single unqualified file + bundle vars, but you give up workspace previewing. Every iteration goes through bundle deploy -t dev.

Until workspace-native editing respects bundle context, the transform-in-CI pattern is the practical answer.