Facility Management

A maintenance system that knows where its assets are — and, because it is built on Omaya, who was near them and what the room was doing at the time.

Who it is for

Maintenance teams	Work orders, on a phone
Whoever owns the asset register	Assets, categories, attachments, QR codes
Whoever plans maintenance	PM schedules, vendors, service history
Building tenants	A public request form — no account needed

Before it is useful

Nothing, to start — you can keep an asset register with no hardware at all. Tags on the assets you want to locate, a linked device on the ones whose readings you want, and app users for the people who do the work.

Assets

Each asset has a category, a space, a parent (so a pump belongs to a plant room belongs to a building), attachments, and a QR code you can print and stick on it.

Three things make it more than a spreadsheet:

Locate. If the asset carries a tag, "where is it" is a button rather than a search of the building.

Live readings. An asset linked to a device shows that device's current readings on its own page — so the chiller's temperature is on the chiller's record rather than in a separate report. The link is explicit: an asset standing near a sensor is not linked to it.

History. Everything that happened to it, in one list.

Work orders

Raise, assign, schedule, comment, complete. Work orders are shared across the platform — Toilet Hygiene's cleaning jobs are work orders too — so a cleaner and a technician each see one list of their own work rather than one list per app. My work is the technician's own view, and there is a calendar of what is scheduled.

Who sees what is a permission, not a filter. An app user's grant for this app carries a data scope: all records, or only the jobs assigned to them and the unclaimed ones. A technician narrowed to their own work cannot open somebody else's job by its address either.

Recurring schedules write jobs as they fire, rather than storing a year of future jobs. Nothing holds "the June service" until the scheduler creates it.

Dispatch shows which staff are on the premises right now, from the same positioning everything else uses, so a job can go to somebody who is actually in the building. Staff can be marked off-premises by hand when the tag says otherwise.

Preventive maintenance

PM is the part that separates this from a job list.

• PM plans per asset — what is due, when, and the history of what was run.
• Compliance view — what is overdue and what is due soon, across the estate.
• Run now — trigger a plan by hand when the schedule and reality disagree.

Vendors and service records

Vendors are the outside parties who do some of the work; jobs and service records can name them.

Service records are the audit trail: every time an asset is cleaned, inspected, repaired or replaced, a record is written. They feed the service history reports and the dashboard, and they are what you produce when somebody asks what has been done to a machine.

Requests from the people in the building

A public form at /{your-organisation}/maintenance-request lets anyone report a problem without an account — a building tenant, a member of staff, a visitor who found a broken tap.

Reports from the visitor app land in the same place.

Those arrive in the tenant request inbox, where the facility team takes a request through reviewing to approved or rejected, converts it into a work order, or closes it. Two clocks run on every open request: after 24 hours without review the administrators are told; after seven days it is flagged as a breach on the request itself.

Reports

Seven: work orders, service history, upcoming work, asset counts, PM compliance, vendor activity and tenant requests. Each has a page and a data endpoint, so the filters are live and the export is CSV.

Where it meets the rest of the platform

• Entities — a tagged asset is an entity, so it appears in the Entity Tracker and in every report about movement. People and assets explains the record itself.
• Jobs the platform raises on its own. Four things create a work order without anybody asking: a battery alert at critical, a device anomaly at warning or critical, a gateway offline for 24 hours, and a meeting room's people counter silent for four hours. These arrive in the same queue with their source marked, and they are why you should not write a rule for any of those four — you would get two jobs for one fault. Two refinements: they are only raised for organisations that have this app switched on (otherwise the alert stands alone), and a configuration anomaly — a device not placed, a reading nobody mapped — never becomes a job, because it is an administrator's two-minute fix, not a technician's. The gateway job closes itself when the gateway comes back, with the outage written into the resolution — unless somebody has already taken it, in which case it is left to them.
• An external CMMS. With a CMMS connector enabled under Integrate, every new work order is pushed out as it is created and marked resolved there when it is closed here. A failed push is logged and never blocks the job.
• App users — the people who do the work sign in as app users, not as administrators.

Rules can raise jobs

Raise a work order is a rule action like any other, so anything a rule can test can become a job: a battery below 20 %, a room that has been too warm for an hour, a gateway that has gone quiet.

You give it a title (with {placeholders} from the rule — {zone_name} is too warm ({temperature} °C) reads as one sentence), and optionally a description, a work type, the role that should see it, and a priority. A zone-scoped rule stamps the zone on the job, so it says which room.

Two templates in the rule gallery use it — Room too warm and Unusual power draw — and both start switched off. Adopt one, set the threshold and the work type that suit your team, then turn it on. They are for things the platform does not already raise jobs for; batteries, anomalies and gateways are handled without a rule.

It raises one job, not sixty

This is the only rule action that leaves something for a person to close, so it behaves differently from the messaging channels on purpose.

A condition that stays true is true every minute. While a job for that rule and subject is open, no second one is raised — and after somebody closes it, it still will not raise another until the cool-off has passed, because closing a job does not make the condition false. The default is 24 hours; you can change it per action, or set it to zero if you really do want a repeat.

It is not permanent, though. Once the cool-off passes the rule may raise again — a battery replaced today drains again in a year, and a rule that could never raise a second job would have quietly stopped working.

When it disappoints

Locate does nothing. The asset has no tag, or the tag is not linked to it.

No live readings. The asset has no linked device — being near a sensor is not the same as being linked to one.

Dispatch shows nobody. Staff have no tags, or nobody is in the building.

Work orders do not reach anyone. The people who do the work need app user accounts; a register with no users is a register, not a workflow.