Home and attention, concepts

Home shows summaries ordered by your personas and limited to the screens available to your account. Plant pulse, work items, production alerts, opportunities, and daily changes link to their full pages. Maintenance, quality, dispatch, performance, and savings cards appear where relevant to your personas. Unavailable data stays visibly unavailable, with a retry action when a request fails. Daily changes compare complete days and leave missing comparisons blank. The Plant results card compares sites when enough data exists. Ask opens from its shared sidebar tool.

See How to navigate quickly for the area map and How to check plant status for machine details.

Domain objects

Alerts

An alert fires when something needs attention: a KPI crosses a configured threshold, an andon call comes in, a preventive maintenance task goes overdue, a tag stops reporting, a gateway stops reporting, a kiosk display goes dark, or the platform itself has a problem. Each KPI rule has two optional settings, edited alongside its threshold on KPI & Alarm Rules, that keep a value sitting right at the line from firing over and over: a hold time (how long the condition has to last before the rule fires at all, so one bad reading does not open an alert by itself) and an alert margin (how far the value has to recover past the threshold before the alert closes on its own, so it does not close and reopen every time the value ticks a hair back over the line). Both come with sensible defaults already applied and can be left blank. Alerts carry a severity, a source, and node context (which site/area/asset triggered it), and start in an open state. Acknowledging one calls POST /alerts/{id}/ack and removes/updates it in place, no full page reload. A condition that trips again later (a rule that closes and re-trips, a display flapping on and off) reuses the same alert row, bumping its count and “last fired” time, instead of opening a new one, so the open list stays one row per distinct problem, not one row per firing. Every individual firing is still kept on record, only the open-list view coalesces.

Every alert falls into one of two types: Production (KPI rules, andon calls, preventive maintenance, the exceptions that need a plant manager right now) or System health (tag health, gateway, platform, and display alerts, infrastructure telling on itself). System health alerts close on their own as soon as the underlying signal is healthy again, no manual acknowledgement needed to clear a tag, gateway, or display that started reporting normally. A gateway that stops reporting raises one alert for the gateway itself, not one per tag on it. Home’s alerts card leads with the Production count and a secondary System health count and link, so infrastructure noise never crowds out a real production exception. The bell in the top bar counts Production alerts only, though its dropdown lists both types together and its “View all” link opens the same Alerts feed. The Alerts feed itself opens on Production by default with a visible Alert type toggle to switch to System health or see everything, plus a filter bar that narrows further by severity, source, node (with subtree roll-up), and free-text search over title/message. A Status filter defaults to Open. Switch it to Acknowledged to review acknowledged history, or All to see both together. Alerts surface in three places: the Alerts feed itself, an “Open alerts” card on a node’s own page, and Shift Handoff’s “open alerts” section (see Floor, Shift Handoff). Notification preferences (which channels an alert reaches you through) are configured on their own dedicated page, see How to configure notification preferences.

Work Items (incidents, andon calls, repairs)

A Work Item puts incidents, andon calls, and maintenance repair requests in one queue and lifecycle. Each item carries a kind (incident, andon, repair), a status (open → in progress → resolved/cancelled), and links back to the same underlying downtime/telemetry data the Floor screens use. An item has exactly one assignee, that’s who owns the work, plus any number of watchers, people or groups who want status changes, comments, escalations, and resolutions without taking ownership themselves. See How to manage Work Items.

An investigation that starts as a kind=incident Work Item stays linked to the Historian slice it was raised from, reopening it jumps straight back to the Historian with the same device and window preselected, and an AI similar-incidents lookup surfaces past incidents that look like the current one. See Improve, incidents and the Historian.

A Work Item’s description and comment thread are there so the next person (or the AI) understands what happened on the machine, not to build a record on whoever wrote them. When that text reaches Ask your factory, it’s credited by role and shift, never by name.

How the pieces relate

Alerts is the raw signal, a threshold crossed. Work Items is the triage/response layer over alerts and downtime: a Work Item can be opened straight from an alert or a downtime event, and stays in one place through acknowledge → in-repair → resolved, instead of forcing a supervisor to track a stop across three different screens. Both feed the same underlying KPI/telemetry data that Floor’s screens present in real time and that Improve’s screens slice, compare, and explain in more depth.