Origin: filed by the domain:devx execution seat (#6023, session session_01Vbw3RPgdtqesx4azk9SbW8, 2026-09-06T08:53Z) from the #16167 dev's open question (PR #16266 report). Left for triage on domain:* and type — the #16167 triage comment (5556889150) reserved the bug call for exactly this shape: existing wording that leads a reader to infer the wrong conclusion.
What
content/docs/ui/dashboards.mdx on origin/main 8adb9e84a:
:353 — the ## Global Filters example: { name: 'region', field: 'region', label: 'Region', type: 'select' }:174-178 — the same page's running sales dataset: object: 'opportunity', include: ['account'], dimension { name: 'region', field: 'account.region', type: 'string' }
Read together, the shared spelling region implies that a filter's field and a dataset's dimensions share one namespace. They do not (PR #16266 now states the rule a few lines below): as a filter field, region resolves against the opportunity object's own fields, which is a different column from the dimension named region (that one is account.region through include). If opportunity has no region field, dashboard-filter-field-unknown (error) fires on the example as written.
Executable criterion
Change the example's filter so it cannot be confused with a declared dimension name — e.g. a field the opportunity object plainly owns and that no dataset on the page declares as a dimension (the dev suggested stage; verify against the page's own object/dataset declarations before choosing) — or, if the intent is to filter on the account's region, show the dotted form field: 'account.region' with include: ['account'] and say that it is the dotted path, not the dimension name, that makes it resolve. One example line; the {/* os:check */} fence stays valid. Region-level surface: the ## Global Filters first example only (PR #16266 lands in the same section — serial after it merges).
Refs #16167 (the rule statement, landing in PR #16266) · #16256 (the generated reference page row).
Generated by Claude Code
Origin: filed by the
domain:devxexecution seat (#6023, sessionsession_01Vbw3RPgdtqesx4azk9SbW8, 2026-09-06T08:53Z) from the #16167 dev's open question (PR #16266 report). Left for triage ondomain:*and type — the #16167 triage comment (5556889150) reserved thebugcall for exactly this shape: existing wording that leads a reader to infer the wrong conclusion.What
content/docs/ui/dashboards.mdxonorigin/main8adb9e84a::353— the## Global Filtersexample:{ name: 'region', field: 'region', label: 'Region', type: 'select' }:174-178— the same page's running sales dataset:object: 'opportunity',include: ['account'], dimension{ name: 'region', field: 'account.region', type: 'string' }Read together, the shared spelling
regionimplies that a filter'sfieldand a dataset'sdimensionsshare one namespace. They do not (PR #16266 now states the rule a few lines below): as a filter field,regionresolves against theopportunityobject's own fields, which is a different column from the dimension namedregion(that one isaccount.regionthroughinclude). Ifopportunityhas noregionfield,dashboard-filter-field-unknown(error) fires on the example as written.Executable criterion
Change the example's filter so it cannot be confused with a declared dimension name — e.g. a field the
opportunityobject plainly owns and that no dataset on the page declares as a dimension (the dev suggestedstage; verify against the page's own object/dataset declarations before choosing) — or, if the intent is to filter on the account's region, show the dotted formfield: 'account.region'withinclude: ['account']and say that it is the dotted path, not the dimension name, that makes it resolve. One example line; the{/* os:check */}fence stays valid. Region-level surface: the## Global Filtersfirst example only (PR #16266 lands in the same section — serial after it merges).Refs #16167 (the rule statement, landing in PR #16266) · #16256 (the generated reference page row).
Generated by Claude Code