Opening the route and using its personal-layout API requires the grantable dashboard:dashboard:read tenant permission. The dashboard_user role template contains this permission; widgets retain their own provider-specific access checks.

Modules contribute widgets through the dashboard.widgets WebUI capability. Personal widget layouts are stored by the backend for each tenant, account, and active View. Configure mode supports adding, removing, ordering, sizing, and widget-specific settings. Existing browser-only layouts are used as a migration fallback until the first server save.

The Dashboard's Active interface modules metric and widget count only tenant-enabled modules whose WebUI is loaded in the current browser session. The Administration module catalogue has a different operator-facing scope: it also includes discovered backend-only and headless module manifests. The two figures therefore need not match.

Widget providers can declare supported sizes and a small configuration schema:

{
  id: "example.summary",
  surfaceId: "example.dashboard.summary",
  title: "Example summary",
  supportedSizes: ["small", "medium", "wide"],
  defaultConfiguration: { limit: 10, showDetails: true },
  configurationFields: [
    { id: "limit", label: "Rows", kind: "number", min: 1, max: 50 },
    { id: "showDetails", label: "Show details", kind: "boolean" }
  ],
  render: ({ configuration }) => <ExampleWidget configuration={configuration} />
}

Every widget needs a matching View surface. The Dashboard catalogue filters contributions through the effective View before rendering them, while saved placements remain intact when a View or module temporarily hides a widget.