Workflows

The Workflows area lets you compose platform primitives into executable company tasks. A workflow combines a trigger with one or more steps, then runs automatically whenever the trigger fires.

After you configure a workflow, it becomes a durable executable version of that task. Each run captures performance data, and agents in the workflow are automatically improved when feedback signals are available.

Configuration

Trigger

Choose the event that starts the workflow.

Trigger	Use it to
Monitor alert	Start a workflow when a monitor alert trips
New hardware data event	Start a workflow when a Thing reports new data
New ingress integration event	Start a workflow when an inbound integration produces an event
Schedule	Start a workflow on a recurring time-based schedule

Steps

Add steps in the order the task should run. Steps are composable and can pass context forward to later steps.

Step type	Use it to
Data query	Read platform data, including telemetry, aggregates, latest values, and related context
Thing command	Send an action to connected hardware
Egress integration command	Send data or notifications to an outbound integration
Agent	Run a forecasting, anomaly detection, integration, or other specialized agent

Executions

Each workflow execution records what triggered the run, which steps ran, their outcomes, and the available performance data. Use execution history to understand whether the workflow completed, where it spent time, and which step produced the result.

If an execution includes an agent and a feedback signal is available, the platform uses that signal to improve the agent automatically.

The closed loop

Workflows are how the platform turns intelligence into action and feeds the result back as new intelligence. Whether a pre-configured or derived Metric Definition; a Monitor watching that metric triggers a workflow that fires through an egress Integration as a work order or alert. When the work is done, its outcome — what the technician found, what the repair resolved — returns through an ingress Integration as a new measured metric, linked to the Things it concerns. That outcome becomes training signal, so the next prediction is sharper than the last.

The loop is grounded by design:

Only measured facts and confirmed outcomes become training labels — a model's own predictions never silently become its own training data.
Inputs respect time — a representation used to predict an event never contains information from after it.
Every result carries its references — the Things, metric values, and linked records behind it — so an alert is auditable rather than an unexplained number.

Worked example: a fast charger fault

A fast-charging unit begins drifting: its behavior is shifting away from its own baseline, not enough to trip a fixed threshold but enough to move its representation. A drift Monitor surfaces it early, and a fault-risk predictor flags the elevated risk concentrated in a specific cohort: units of one Thing Type on a particular firmware revision (a property) within a region (a Place). A Monitor fires through the egress Integration into the field-service system, dispatching a work order scoped to exactly that cohort and carrying its references. Technicians replace the connectors, the resolved work orders return through the ingress Integration as confirmed outcome metrics, and the predictor retrains on them — so the next cohort like this one is caught earlier and scoped more precisely.

Worked example: a golf cart battery fault

A golf cart's lithium battery pack starts to misbehave: a growing cell-voltage imbalance and a rising pack temperature under load push the cart's representation away from the healthy fleet, well before any single reading trips a limit. A drift Monitor catches the early signal, and a fault-risk predictor — trained on the shared representation — estimates a high probability of a pack fault in the coming days, scoped to a cohort: carts of one Thing Type running a particular battery module (a property) at one course (a Place).

Catching it is only half the fix. Because the prediction carries the cart's identity, location, and the specific failing module, a workflow fires through an egress Integration to pre-position the replacement — reserving the correct battery pack from inventory and staging it at the course before the cart is pulled from service. A second egress step dispatches a work order scoped to the at-risk cart that carries its references: the drift evidence, the predicted fault, the battery module and its linked service manual, and the technician notes from prior pack swaps on this cohort.

That bundle is what drives first-time fix rate. The technician arrives with the right part already on site and the exact diagnosis and procedure in hand, so the repair is completed on the first visit instead of a diagnose-now, return-later trip. When the work order closes, its outcome — the confirmed fault, the part used, and whether it was fixed on the first visit — returns through an ingress Integration as new measured metrics linked to the cart. First-time fix rate becomes a tracked outcome metric, and the predictor and parts-staging logic retrain on it, so the next at-risk cart is caught earlier, staged more accurately, and resolved in a single visit more often.

Common patterns

Alert response: a monitor alert triggers a workflow that queries recent data, runs an anomaly detection agent, and notifies an operator.
Hardware action: a new hardware data event triggers a workflow that evaluates current state and sends a Thing command.
Integration handoff: a new ingress integration event triggers a workflow that runs an integration agent and sends the result to an egress integration.
Scheduled planning: a schedule triggers a forecasting agent and pushes the forecast to a downstream system.

Monitors can trigger workflows from alerts.
Integrations can produce ingress events or receive egress commands.