Dashboard Configuration

Configure which widgets appear on the technician dashboard, their data sources, labels, and stage layouts.

What this page does

The Dashboard page controls the technician frontend's widget layout and behavior. Every widget on the technician dashboard -- from AI Assessment to Telemetry to Job Queue -- is configurable here. You control which widgets are enabled, what data sources they use, what roles can see them, and how they're arranged in each workflow stage.

Changes made here are stored in the tenant's dashboard configuration and take effect immediately on the technician frontend.

Each widget has a configuration card with the following fields:

Field	Description
Enabled	Toggle the widget on or off. Disabled widgets do not appear on the technician frontend and their API endpoints return empty responses.
Label	Display name shown in the frontend. Override the default (e.g., rename "AI Assessment" to "Diagnosis" for your team).
Data Source	Where this widget gets its data. See data source types below.
Integration	When data source is `integration`, select which configured integration provides the data.
Role Visibility	Which roles can see this widget. Empty means visible to all roles.

Available widgets

Widget ID	Default Label	Default Source	Description
`assessment`	AI Assessment	Intelligence	AI-generated summary, confidence badge, diagnosis cards
`procedure`	Procedure	Intelligence	Step-by-step instructions with safety refs and CKL refs
`safety`	Safety Warnings	Intelligence	ANSI Z535 severity-tagged warnings with citations
`parts`	Parts	Intelligence	Parts list with P/Ns, quantities, verification flags
`specifications`	Specifications	Intelligence	Key-value specification pairs from documentation
`citations`	Citations	Intelligence	Source document references and page images
`queue`	Job Queue	Mock	Work order queue from DMS
`job_summary`	Job Summary	Mock	Work order details and Three C's close-out
`fault_codes`	Fault Codes	Mock	Fault codes from DMS or telemetry
`telemetry`	Telemetry	None (disabled)	Real-time engine event data
`vitals`	Engine Vitals	None (disabled)	Current engine readings (RPM, temp, pressure)
`customer`	Customer	None (disabled)	Customer info and service history

Data source types

Source	Label	Description
`intelligence`	Intelligence	Data from the Planara intelligence pipeline. The widget calls a Widget API endpoint that projects from a stored query response.
`integration`	Integration	Data from an external system (DMS, telemetry, ERP) via a configured integration. When selected, you must also choose which integration provides the data.
`mock`	Mock	Demo data served from built-in mock endpoints. Useful for demos and development before real integrations are connected.
`none`	Disabled	No data source. The widget is hidden regardless of the enabled toggle. Use this to park widgets you plan to activate later.

How data sources flow

Dashboard Config (tenant configuration)
    │
    ├── intelligence → /v1/widgets/{ns}/{widget}?session_id=...
    │                  (reads from stored query responses)
    │
    ├── integration  → /v1/widgets/{ns}/{widget}
    │                  (dispatches to configured adapter)
    │
    ├── mock         → /v1/widgets/{ns}/{widget}
    │                  (returns built-in demo data)
    │
    └── none         → widget hidden, endpoint returns empty

Stage layout editor

The technician frontend uses a stage-based workflow: queue, assess, repair, verify, close. Each stage has a layout configuration that controls which widget is the hero (full-height left panel) and which widgets appear in the scrollable right rail.

Layout structure

Field	Description
Hero	The primary widget that fills the left panel. One per stage.
Rail	Ordered list of secondary widgets in the right scrollable column.
Auto-fetch	When enabled, the stage automatically triggers a query when the user navigates to it (e.g., the assess stage fetches an AI assessment as soon as a work order is selected).

Default stage layouts

Stage	Hero	Rail	Auto-fetch
Queue	Job Queue	Job Summary	No
Assess	AI Assessment	Fault Codes, Customer, Vitals	Yes
Repair	Procedure	Safety, Parts, Telemetry, Specifications	No
Verify	Job Summary	Safety, Citations	No

Tapping a rail widget on the technician frontend promotes it to the hero position. The previous hero moves into the rail. This is a user interaction -- it does not change the configured default.

Role visibility

Use the Role Visibility field on each widget to control which roles can see it. This works alongside the role-level settings on the Roles page.

Empty list -- widget is visible to all roles
Specific roles (e.g., ["technician"]) -- widget is only visible to users with one of those roles

Examples:

Fault Codes widget with ["technician"] -- owners do not see fault code data
Telemetry widget with ["technician"] -- only technicians see real-time engine telemetry
AI Assessment with [] -- visible to everyone

The technician frontend calls GET /v1/config/{namespace}/dashboard?role={role} at load time. The API filters the widget list based on role visibility before returning it, so the frontend never receives widgets the user should not see.

How changes propagate

You update a widget configuration on this page and save
The backoffice calls PUT /v1/config/{namespace}/dashboard with the new config
The config is persisted to the tenant's dashboard configuration
The technician frontend reads the config on next page load via GET /v1/config/{namespace}/dashboard
Widgets render (or hide) based on the new configuration

There is no deploy step. Changes are live as soon as the technician refreshes or navigates.

API reference

Method	Path	Description
`GET`	`/v1/config/{namespace}/dashboard`	Read dashboard config, optionally filtered by `?role=`
`PUT`	`/v1/config/{namespace}/dashboard`	Replace dashboard config (widgets and/or stages)

GET response shape

{
  "widgets": [
    {
      "id": "assessment",
      "enabled": true,
      "label": "AI Assessment",
      "data_source": "intelligence",
      "role_visibility": [],
      "settings": {}
    }
  ],
  "stages": {
    "assess": {
      "hero": "assessment",
      "rail": ["fault_codes", "customer", "vitals"],
      "auto_fetch": true
    }
  }
}

PUT request body

{
  "widgets": [
    {
      "id": "telemetry",
      "enabled": true,
      "data_source": "integration",
      "integration_id": "telemetry-001",
      "label": "Live Telemetry",
      "role_visibility": ["technician"],
      "settings": {}
    }
  ],
  "stages": {
    "assess": {
      "hero": "assessment",
      "rail": ["telemetry", "fault_codes", "customer"],
      "auto_fetch": true
    }
  }
}

Multi-procedure assessment

The assess stage supports confidence-driven hero selection. When the pipeline identifies multiple plausible diagnoses for a query (e.g., an overheating complaint that could be thermostat, water pump, or sensor-related), the assessment hero displays each as a tappable diagnosis card with:

Procedure title and confidence score
Key differentiating detail (why this diagnosis vs. the others)
Tap action that loads the corresponding procedure into the repair stage hero

This replaces the previous single-diagnosis model. The dashboard configuration controls which diagnoses appear (confidence threshold) and whether the assess stage auto-fetches multiple procedures or waits for user interaction.

Multi-tenant frontend routing

The technician frontend supports multi-tenant routing via namespace URL segments: /{namespace}/. For example, /yamaha/ and /honda-8/ load different configurations, documents, and branding. The namespace is extracted from the URL path and passed to all API calls.

Dashboard configuration is fully isolated per namespace -- widget layout, data sources, stage ordering, and role visibility are all tenant-specific.

Widget API -- the endpoints that serve widget data
Diagram Highlighting -- how highlighted diagrams appear in procedure steps
Context Streams -- the 8 data streams injected into queries
Roles and Permissions -- role-level content controls
Integrations -- configure the external systems that feed integration-derived widgets