Maintenance That Is a Movement, Not a Plan
This product has two constants named for maintenance and nothing that writes either of them. That is a more useful thing to know than a roadmap promise, and it is the second time the same shape of defect has been found here — a feature that exists as vocabulary and not as behaviour.
A maintenance module is the single most-requested thing missing from this asset register, and the honest description of what is here is shorter than most people expect: two enum values, no writer, no schedule, no work order, no meter.
The position, stated first
If preventive maintenance scheduling is why you are evaluating an asset module, this is not the product today. Everything below is about why we would rather tell you that on the first page than let you find it in month four — and about the specific way this gap used to hide, which is worth knowing whoever you buy from.
What a maintenance feature normally means
The phrase covers at least five different systems, and vendors rarely say which one they mean. It is worth separating them before comparing anything.
Five things called "maintenance", and which are here
| Capability | Built | Recorded | Absent |
|---|---|---|---|
| A service schedule per asset or class | No | No | Yes |
| A next-service-due date that alerts | No | No | Yes |
| Meter or running-hours capture | No | No | Yes |
| A work order with parts and labour | No | No | Yes |
| A record that the machine went away and came back | No | Partly — configurable by you | No |
| Downtime measured as a duration | No | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The fifth row is "part" rather than "yes" for a specific reason, and it is the subject of the next section.
The half-row, and why it is a half
The asset movement model declares twelve actions. Two of them are sent to maintenance and returned from maintenance. For a long time the movement-action filter on two separate screens was populated straight from that list of twelve.
Nothing in the codebase ever wrote either value. So a user could open the movement report, select "Sent to maintenance" from a dropdown the product itself offered them, and receive an empty table — not because no machine had been serviced, but because the action could not be recorded in the first place.
A filter that can only ever return nothing is worse than a missing filter. The missing one prompts a question; the empty one answers it, wrongly.
That was corrected by splitting the declared actions from the recorded ones: the filter now offers only the nine actions the services actually write. The two maintenance constants are still declared, because removing them would be a schema change for no gain — but they are no longer presented to anybody as something they can look for.
What you can do instead, and what it costs you
-
Use transfer to a maintenance location
Create a location called Workshop and transfer the asset to it. The movement carries the actor and the time, so "when did it go in" and "who sent it" are answered properly. This is the workaround and it is not a bad one.
-
Read downtime as the gap between two movements
Out on the 3rd, back on the 11th, eight days. Correct, and computed by a person from two rows rather than by a report from a field.
-
Keep the schedule where the schedule lives now
A spreadsheet or a wall planner. The system will not remind you, and pretending otherwise is how a service gets missed by a fleet that believed it was covered.
-
Attach the service report to the asset
Document storage against an asset works, so the evidence of what was done is retrievable even though the scheduling of it is not.
What that workaround does not give you is the only thing a maintenance module is really for: being told before the service is due rather than after. Everything above is retrospective. A machine that should have been serviced in June and was not will look identical to one that was, until it stops.
The related gap, since we are here
Document expiry reminders exist and work — a thirty-day warning, respecting notification preferences. They are filtered to two model classes: employees and employment contracts. The identical field on the identical table attached to an asset produces nothing. So a work permit gets a warning and a plant insurance certificate gets silence. That is one filter clause, and it is named in the gap file as such.
Three, and the cheapest one is the one worth doing first
This is well-understood territory. The order below is deliberate — it is ascending in cost and descending in how many businesses actually need the next step.
A next-service-due date that alerts
One nullable date on the asset, one daily sweep, one notification honouring the preferences that already exist. This is small, and it converts the register from a record into a system that tells you something. The plumbing is already there — it is what the document-expiry reminder does for employees today.
Meter and running-hours capture
A reading per asset with a date, and intervals expressed in hours or kilometres rather than months. This is what a generator, a truck or a compressor actually wears out on. It is a bigger job because it needs a capture habit as well as a table, and a meter nobody reads is worse than a calendar.
Work orders with parts and labour
The full thing: a job raised against an asset, parts issued from stock against it, labour recorded, cost accumulated and closed. This is a project rather than a feature, and it is genuinely the right answer for a business whose equipment is its product. We would scope it as one and say so.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. The first item above is days, not weeks — if it is what you need, say so.
Talk to us about maintenance schedulingWhat AWRA OpsHub does today
- Nine recorded asset movement actions, each with the person and the time: check-out, check-in, transfer, relocation, verification, damaged, lost, retirement, approval.
- Locations, so a workshop can be modelled and a machine can be shown as being at it.
- Document storage against an asset, so service reports and certificates are retrievable.
- A movement filter that offers only actions something can actually write.
What it does not do
- A preventive maintenance scheduler. No service intervals, no next-service-due date, no reminder.
- Meter, odometer or running-hours capture of any kind.
- Work orders. No job, no parts issued against a repair, no labour, no accumulated repair cost per asset.
- Downtime as a measured quantity, and therefore no availability or utilisation figure.
- Calibration records and calibration due dates.
- A maintenance movement action that anything writes — the two constants exist and are dead.
Not ours, by choice
- A dead model in this codebase already carries last-maintenance and next-maintenance date fields with no controller, route or reader behind them. The schema for the smallest version of this exists; the behaviour does not.
- Service-schedule claims were, at one point, the widest single copy defect in this corpus — about thirty assertions across fifteen files. They are corrected, and this page is written on the other side of that. If you find one we missed, it is a bug and we want to know.
- Nothing here is Egyptian. Cairo is here as a market where plant runs hard, spares travel, and an unplanned stoppage costs more than the service would have.
Four questions that separate a maintenance module from a maintenance label
Show me an asset with a service due next month.
A good answer sounds like
They filter a list and it has rows.
What it actually means
This is the whole test. A demonstration that navigates to a blank form instead is showing you a field, not a feature.
What writes the maintenance record — a person, or a schedule?
A good answer sounds like
A schedule creates it, a person closes it.
What it actually means
If a person creates it, the system is a filing cabinet for work already decided elsewhere.
Can an interval be expressed in hours rather than months?
A good answer sounds like
Yes, with a meter reading.
What it actually means
Calendar-only intervals do not fit generators, vehicles or pumps, which is most of what anybody wants this for.
What is the total repair cost of this asset to date?
A good answer sounds like
A number, from work orders.
What it actually means
Without work orders there is no such number anywhere, and replace-or-repair stays a matter of opinion.
Ask the dropdown question
In any demonstration, pick a filter the vendor offers you and ask them to run it against real data. An option that returns nothing on every dataset is a feature that exists as vocabulary. We had one, on two screens, and this is the page that came out of fixing it.
Talk about asset operationsFrequently asked questions
Can I record that a machine is being serviced at all?
Yes, as a transfer to a workshop location, which carries the actor and the time. What you cannot do is have the system tell you in advance that it is due, or record what the service cost.
Why leave the two dead constants in place?
Removing them is a schema change with no user-visible benefit, and they are no longer offered to anybody. The defect was that they were rendered into a filter, and that is fixed. If the feature is ever built, the constants are what it will write.
Does the asset register alert me about anything?
Not on a date it holds itself. Reminders exist in the product and work well, but they are wired to employee documents; extending them to assets is one filter clause and it is named as a gap rather than described as done.
