Why configuring FSM software is broken

Every field service and maintenance platform ships with a workflow builder. Boxes, arrows, a trigger on the left, an action on the right. The sales demo builds a rule in ninety seconds. The implementation takes four months. The gap between those two numbers is the subject of this piece.

Configuration is translation

The person who knows how the operation runs can describe it in one sentence. “When a quarterly inverter service closes with any reading out of tolerance, open a thermography follow-up in the electrical queue and tell the site lead.” An operations manager says that without thinking.

The person who can make the software do it needs something else entirely. They need to know which object the trigger hangs off, which status transition counts as “closes”, where tolerance lives in the data model, what a queue is called in this tenant, and whether “tell” means email, SMS, or a task. So the sentence goes into a workshop, comes out as a requirements row, gets built by a consultant in the builder, gets tested against three made-up work orders, and goes live.

Somewhere in that chain the meaning changes. Not dramatically. “Any reading” becomes “the readings we remembered to model”. “Tell the site lead” becomes “notify the user in the Site Lead role, if one is assigned”. Each step is defensible. The rule that goes live is a paraphrase of the one that was asked for, and no one re-reads it after week sixteen.

The builder is a programming language with a worse editor

No-code builders are sold as the thing that removes the consultant. In practice they move the consultant’s work into a canvas that hides the program’s structure while keeping all of its difficulty. You still have to know the data model. You still have to know the evaluation order. You cannot diff two versions. You cannot ask the canvas what it would have done last March.

The tell is who ends up using it. Watch any deployed system for a year and count how many rules were authored by an operations person after go-live. The answer is usually zero. The builder is used once, by an implementer, during the project. After that, changing a rule means raising a ticket, which means the configuration freezes at whatever the operation looked like in the implementation quarter.

What freezing costs

Operations drift. A new asset owner arrives with a different reporting cadence. A subcontractor is added who is not allowed to close statutory work. A BESS container joins a solar-only portfolio with a maintenance regime that was never templated. Each of those is a rule change. Each one waits for someone with builder access and a spare afternoon.

Meanwhile the work still happens. It happens outside the rule, in a WhatsApp thread or a spreadsheet column, and the system records a version of the operation that stopped being true months ago. When the asset owner disputes an SLA, the evidence reflects the rule as configured, not the work as done.

What authoring should look like

The sentence the operations manager said was already precise enough. The fix is to accept it as the authoring interface and move the rigour to the two places it belongs.

First, the read-back. The system compiles the sentence to a rule, then renders the rule back as unambiguous structured English: when this event, if these conditions, then these actions, never these. Every assumption it had to make is listed. “I have taken ‘out of tolerance’ to mean the asset’s configured parameter limits. Correct?” The operator approves the read-back, not the prose they typed. That is where the meaning stops leaking.

Second, the backtest. Before a rule is switched on, it is run against the last twelve months of the operation’s own history. “This would have fired 46 times last year. Here are all 46, with the work order each one would have opened.” A rule that would never have fired gets a warning. A rule that would have fired four hundred times gets a different one. The operator sees the rule’s behaviour on their real past before it touches their real future.

Under this model the boxes-and-arrows canvas is not deleted. It becomes documentation: a read-only view of what is active, with its English read-back, its version history, and its firing count for the last thirty days. That is a useful thing for a canvas to be. It was never a good thing to author in.

Where we are with this

Facterra’s workflow engine has stored rules as declarative data since the beginning, which is what makes them a compilation target rather than code. The English-in, read-back, backtest-before-activation flow is what we are building on top of it now, with two constraints fixed in advance. The compiler cannot produce a rule that opens statutory or safety work to an external party, and it cannot bypass a signature requirement. If a request needs either, it is refused with the reason. That part is not shipped today; it is what we are building next, on an engine that has been in production since 2017.