Dashboards and widgets

Create a Custom dashboard App in Operations Studio for new dashboards. It starts with current production KPIs, a chart and a breakdown table. Layout, theme, chart options and calculations are editable App source; Konnie can adapt them to your needs.

Create a custom dashboard

1. Create an App and choose Custom dashboard. The starter reads current production orders; it creates no example records.
2. Open Data & actions to connect production data or a user-defined Table. Each connection has a stable source alias.
3. Adjust the dashboard settings for its source alias, grouping and numeric fields. Use Files or ask Konnie to change formulas, charts, labels and layout together.
4. Preview the result and compare the totals against the intended data. Save and publish separately for the assigned audience.

For example: “Use my energy Table to show energy per finished part by machine. Calculate the ratio from the summed energy and summed parts, and show missing denominators.” Konnie can inspect the authorized schema and build the App without a predefined KPI catalogue. Tell it the intended units and reporting period.

The starter shares one query across its cards, chart and breakdown. Source-change hints trigger an authorized refresh, with at least five seconds between data reads; a visible 30-second poll reconciles missed hints. Schema discovery runs less frequently. Hidden or offline Apps pause expensive refreshes and reconcile when resumed. Temporary throttling respects the server retry time and keeps the last authorized result visible; a permission or schema error hides it. Ordinary refresh preserves zoom and legend choices.

Queries return a complete result or an explicit limit error. Narrow an oversized query instead of treating a page as a total. Current order quantities are a snapshot, not historical throughput. For workplace-specific output use production splits and agree the calculation's grain. Existing integration workflows can populate authorized Tables; direct arbitrary network/database access from Apps is unavailable.

Define a reporting window

Native connections include current orders, production splits and work-center state, production event deltas, and malfunction intervals. Connect the source, select its fields and define the meaning of your calculation in App code or with Konnie. There is no fixed KPI catalogue.

For a production history chart, use productionEvents, the timestamp grouping field and quantityDelta as the actual value field. Clear unused planned/scrap mappings. Set the reporting hours or both explicit start/end instants, then choose a time bucket and timezone. Rolling windows advance during refresh; fixed windows keep their endpoints. Windows are half-open: start is included and end excluded, with a maximum span of 366 days.

For downtime, use malfunctions and durationMs. Durations are clipped to the selected reporting window. When grouped into time buckets, an interval contributes its overlapping duration to each bucket; a per-bucket count means overlapping intervals, not distinct incident starts. Keep units, grouping and counting meaning visible.

Historical results report the latest matching event time or visible interval update alongside the fetch time. This is a record watermark, not connector health: an idle machine can legitimately have no recent event. Current snapshots do not reconstruct past output. Upstream integrations still need their own synchronization/health checks.

Existing widgets and chart components

Existing Apps can continue using their configured widgets and ECharts component. The following sections describe those existing controls.

Choose a widget

The Analytics palette includes production-rate gauges, current-period throughput, throughput history, backlog/delayed-backlog summaries, backlog charts, downtime, malfunction counts/reason breakdowns, work-center status and Edge health/log/alert widgets.

Select a widget and configure the work center or group, period or history interval, display unit and other offered controls. For backlog, count of orders and total number of parts answer different questions. A production-rate target is a comparison setting; it does not change the underlying recorded production.

For example, a line dashboard can show work-center status, today's throughput, current malfunctions and delayed backlog. Check each widget's scope. Similar titles do not guarantee identical periods, quantities or refresh behavior.

Create an ECharts chart

1. Add ECharts from Analytics in the App builder.
2. Open its chart editor. New charts use the sections Queries, Transformations and Visualization.
3. Configure data or supply inline input, then inspect the table preview.
4. Add transformations if the visualization needs a prepared result.
5. Write the ECharts visualization, or ask Konnie for the code, and inspect chart and table previews.
6. Choose Apply to put the editor changes into the App draft. Save and publish the App separately.

The expanded editor keeps preview alongside the controls. Preview query results are temporary and are not saved into the App. Changes stay in the chart editor until you apply them.

Query operational data

Add a named query, such as orders. Current native datasets are production orders, order execution splits and work centers. Choose Rows for explicit records or Aggregate for count, sum, average, minimum or maximum, optionally grouped by an allowed field. The editor offers the dataset, result shape, calculation, grouping and date range.

Date ranges are inclusive and interpreted in UTC. Date grouping supports day, week and month; weeks start Monday. A grouped result contains group, value and recordCount. Missing groups can be null; intervals with no records are absent rather than filled with zero.

These queries read current operational snapshots. Summing produced quantities by planned date does not measure historical throughput. For a custom App historical calculation, connect the production-event source and specify its reporting window.

Limits are five named queries, 1,000 complete rows and 200,000 serialized bytes per query, with 450,000 combined result characters. Date-range endpoints may be at most 366 days apart. An oversized query fails instead of silently truncating; narrow it or aggregate on the server. Query access is checked for the author and again for each viewer of the published App.

Arbitrary SQL, user URLs and integration actions are not chart query sources. Only the datasets offered by the supported query contract are available.

Transform the result

Select an input query in Transformations, then add and reorder steps:

Step	Behavior
Filter	Keeps rows that satisfy a typed equality/comparison or literal text condition.
Rename	Changes a field ID without changing its values. An existing-name collision fails.
Calculate	Adds a numeric field using addition, subtraction, multiplication or division.
Join	Combines two already authorized query results with a left or inner join.

Inspect each step's input/output tables. Later steps use the previous output. Null arithmetic and division by zero produce null; numeric strings are not converted automatically. Joins use exact typed keys, ignore null key matches and can multiply rows when several records match. Check that multiplication before using totals.

A pipeline supports ten steps; each stage is bounded to 1,000 rows and 200,000 bytes. Transformations work on the returned data in the browser. They do not issue another query or make separate source reads into one transactional snapshot.

Write the visualization

The program returns an ECharts option object. With a pipeline, use data.output.rows; original named results remain available as data.orders.rows and inline input as data.inline.

const rows = data.output.rows;
return {
  tooltip: { trigger: "axis" },
  xAxis: { type: "category", data: rows.map((row) => row.group) },
  yAxis: { type: "value", minInterval: 1 },
  series: [{ type: "bar", data: rows.map((row) => row.value) }],
};

Use Build chart from input for a bar-chart starting point when output has suitable category and numeric fields. Native ECharts series, formatters and callbacks are supported. Chart programs run in the isolated App runtime. They receive explicit chart data and presentation objects; they do not receive account credentials or unrestricted server/database access.

Existing charts can still use the simpler inline chart settings for bar, line, area, pie and donut charts. There, each row is a category in its original order; use JSON numbers for numeric values. Pie/donut charts use one nonnegative series. Repeated labels are not automatically grouped. Inline values remain a saved snapshot until the author updates and publishes them.

Refresh and troubleshoot

Run queries starts the editor preview. The chart-wide refresh interval is manual by default; choose a preset or a whole number from 5 to 86,400 seconds. Runtime charts query on opening and can refresh manually or at that interval. Polling waits until the previous request batch settles before starting its timer; it is not streaming.

The prior chart remains visible during an ordinary refresh. A failed refresh or transformation replaces it with an error; a source or scope change hides the old data. Repair the failed query/step and refresh. Check the table preview when a chart looks empty, and check that the program returns a valid option object when data exists but rendering fails.

Before publication, compare values with the source module, test an empty period and inspect the published App as its intended audience. Keep metric definitions, units and scope visible alongside the chart.