A trigger is a standing rule on a piece of equipment. It writes the work order, fills in the asset, the floor, the room and who it goes to, and does it again on the cadence you set.
Nobody has to remember. The rule is on the building.
A trigger sits on a piece of equipment on the building record. It knows what it is for, how often, and what to create.
Maintenance Scheduler is a tab on the building record, sitting beside that building's floor plans, its rooms, its assets and its work orders. Every standing rule for the building is one row, next to the work order it produces. The programme is something you can read rather than something people remember.
Naming an asset is required before a trigger can be saved, exactly as it is on a work order. There is no standing rule for the building in general. It belongs to a unit, and so does everything the rule goes on to create.
Repeat it regularly or run it once. Every three months, every two weeks, or on a named day of the week. You give it a day to start and a date to stop, and you are describing a rhythm rather than booking a calendar entry.
Its name, its description, its category, its priority and how long it is due in are all set when you build the trigger. So is the location, which comes off the building you are already inside. When the order arrives it is not a stub for somebody to finish.
Priority, assignee, category or equipment, and the columns sort. There is no status filter here, and that is the point: a work order has a status because it is a job, and a trigger does not because it is a rule.
The same rule at four moments. Watch where the work order comes from, and what it already knows when it arrives.
Name it, pick the unit, choose how often, give it a date to stop. This is the only part a person does, and after this nobody has to remember anything.
It lives on the building record with the equipment it belongs to and the person it goes to. It can also be run on the spot when you want the work brought forward.
The order appears in Work Orders with the unit, the floor, the room, the assignee and the due date already on it. Nobody typed an address into a description box, because nobody typed anything.
Next cadence, same rule, same piece of equipment. Which means the unit builds a run of work you can read back: what was done, when it was done, and by whom.
One rule, set up once. Everything after the first panel happens without anybody being asked.
Most planned maintenance is scheduled somewhere. The question is whether the schedule survives the person who set it up.
None of this depends on anybody remembering to look.
These are structural, not measured. They describe how the product is built, not results from a customer. Ruya does not publish numbers it has not earned.
The unit, the room, the category and the priority are on the order the moment it appears, because they were set on the rule.
The order is created before its due date, so the work is in front of you with room to plan it rather than on the day it was needed.
A trigger can be run on the spot when a unit needs attention sooner than the cadence says.
Every standing rule on the building, with the equipment it belongs to and the work order it writes.
Every trigger carries an end date you chose, so a rule that has outlived its reason shows up instead of running on unnoticed.
The rule lives on the building record, not in the calendar of whoever set it up.
How often a unit is meant to be serviced is a field on the building, not a recollection.
Each order the rule wrote carries what was done, by whom, on what day, with a photo on the update.
Beside that building’s floor plans, its rooms, its projects and its binder.
It names a unit, in a room, on a floor, in a building. All four exist in Ruya before the rule does.
What a trigger writes is a work order, and what it is raised against is an asset on the building. The room it happens in carries its own department and use in the room record, and that room sits on the current floor plan for the floor. The unit’s manual and warranty arrived in the closeout folder of the project that installed it.
Hospital maintenance software schedules and documents the recurring inspection, testing, and maintenance (ITM) a hospital's life safety and utility systems require, at the frequencies set by NFPA codes and the hospital's accreditor. Facilities teams use it to prove to Joint Commission (JC), DNV, and CMS surveyors that every scheduled task was completed on time, with the record to show it. Ruya Maintenance Scheduler is a software and service solution: the PM register lives per building, and a failed inspection result opens a corrective work order automatically.
A trigger is a standing rule on a piece of equipment that creates a work order on a cadence you set. It lives on the building record, under Maintenance Scheduler, beside that building's floor plans, rooms, assets and work orders. The product calls the record a trigger rather than a schedule, because it is a rule that fires rather than a date in a calendar.
It creates the work order. The name, the description, the category, the priority, how long it is due in, the equipment and the person it goes to are all set on the trigger, so the order arrives already written. Nobody gets a nudge that then needs turning into a job.
No, and that is deliberate. Naming an asset is required before a trigger can be saved, the same rule work orders follow. A standing rule for the building in general is the thing that quietly turns into nobody's job, and it is also what makes a unit's history unreadable two years later.
No. You set the cadence, and it is yours to set. A lot of hospital intervals are set by code rather than by preference, such as the inspection and testing frequencies in NFPA standards for fire protection equipment, and those are decisions your own people and your authority having jurisdiction make. What Ruya does is hold the interval on the building where everyone can see it, and act on it without being reminded.
No. Every trigger carries an end date, and it is a required field, so a rule cannot outlive the reason it was created without somebody choosing to extend it. A trigger can also be set to run once rather than regularly, and any trigger can be run on the spot when work needs bringing forward.
It behaves like any other work order in Ruya. It gets an owner, it gets worked, and the update thread carries what was actually done, with the name of the person who did it, the date, and a photo. The record stays on the equipment and on the building, which is where the next person will start.
The one where the last service is somebody’s best guess. We’ll put it on a building in Ruya, set the rule that keeps it serviced, and you can watch it write the work order. Twenty minutes, with the founder, not a sales rep.
Rashad Mujeebuddin, Founder, Ruya
On your schedule — no prep needed.