What Actually Does the Work: Workflows and the Closed Loop
A recommendation that nobody acts on is a dashboard with extra steps.
Underneath TwinWorX is a workflow engine, and it is the same engine that handles the integrations. It is not a separate automation product added afterwards. That one fact decides most of what follows.
Composed, not coded
Workflows are built on a visual canvas from blocks that already know how to talk to your building systems, your maintenance system, your notification channels, the rule library, and the model itself. The integration work was done once, in the platform. Your team assembles behaviour rather than commissioning software.
Workflows run on the semantic model rather than on vendor point names, so one workflow runs against any building automation system. The historian, the alarms, and fault detection see every variable a workflow touches, with no second integration layer to maintain.
Each workflow is versioned and testable, and readable by the people who own the process rather than only by developers. Your team can inspect them, adjust them, and in time write them.
Most of it is not faults
It is a general engine for sequences and logic, and most of what it ends up running has nothing to do with fault detection:
A building start-up that brings plant, lighting, and access up in order, with holiday rules and priorities that resolve their own conflicts.
A response in one system to something that happened in another.
Maintenance triggered by how much equipment has actually run, not by the calendar.
Cleaning routes set by real occupancy.
A procedure your team performs today by hand, from a checklist.
Faults are one case. They are the one worth describing in detail, because they show the whole loop.
From a fault to a closed work order
Enriched before it goes anywhere. A detected fault picks up what the model knows: the asset and where it is, how critical it is, what it affects downstream, the probable cause, the supporting trends, the procedure that applies, and the warranty status.
Routed. Then it becomes a notification, an escalation, or a work order raised in your maintenance system, with all of that already attached. The technician arrives knowing what they are walking into.
Closed. When the work order closes, the status comes back to the platform and attaches to the condition that raised it. What the technician actually found becomes the evidence that tunes the rule for next time. That closure also lets the platform tell a genuinely healthy period from a quiet one, which keeps its sense of normal honest.
Kept quiet. Suppression, deduplication, and correlation are built into that path. Repeat faults, duplicates, and the cascade of symptoms from one root cause are collapsed before anything reaches your queue, because a system that raises five tickets for one broken valve gets ignored, and then switched off.
Why it matters in year three
Connecting a detected condition to a business outcome has historically been a development project: quoted per interface, re-quoted whenever the process changed, and priced out of existence for anything of moderate value.
Here it is a change made in the designer. The economics are cumulative rather than headline. Each new workflow reuses the integrations already in place, so the many moderate-value use cases that a per-interface price would never justify become worth doing, and improvements get made while the need is still current.
To state it plainly: authoring a workflow is design work. It deserves to be scoped as project hours, not sold as configuration. What changes is that the work is done once, in a tool your team can read, rather than in custom code only a vendor can change.
Where it leads
The same engine is what Stage 3 runs on. When your team trusts a strategy enough to move it up the autonomy ladder, from advising, to approved actions, to actions the platform takes on its own, the workflow that carries it out is the same one your team has been reading all along.
Bring us the procedure your team runs by hand.
Thirty minutes with one of our engineers, and we will show you what it would look like as a workflow.
