Preventive Maintenance Plan Data Model: Fields and Triggers

Key takeaways

• A preventive maintenance schedule is four objects, not one: the PM plan (the rule), the task list (the steps), the work order (one dated instance) and the completion record (the evidence).
• The plan is the template and the work order is a copy of it. Editing the copy changes one job and never the rule, which is the most common preventive maintenance data defect.
• Four triggers cover every asset: calendar, meter or operating hours, cycles or strokes, and condition. A lead time written in days has to be converted into meter units before anything can be raised.
• Floating counts from the last completion, fixed keeps the original grid. Worked below: one job done 9 days late costs a floating plan one occurrence a year, and a habitual 9 day slip costs three.
• Worked below: 86 of 120 assets covered is 71.7% PM coverage, and deleting 9 skipped jobs lifts schedule compliance from 64.9% to 69.1% with no extra work done.

Four objects, not one

Most preventive maintenance problems are not scheduling problems. They are modelling problems, and they start when a plant keeps the rule and the job in the same record.

This page is the data model behind a schedule: the tables, the fields and the arithmetic. For how to build the schedule as a practice, see our guide to the preventive maintenance schedule.

The plan lives forever and changes rarely. The work order lives for days and changes constantly.

Template and instance: the mistake that eats a year

A technician runs the 500 hour service on the filler and finds the checklist has no step for the second grease point.

He adds it to the work order in front of him, and next month the same job arrives without it, because he edited the instance and not the template.

The reverse version is worse. A planner pushes the due date on the work order to next week, believing the plan has moved, and the plan raises the following job on the old rule anyway.

Two rules stop the confusion. Show the plan identifier on every generated work order, and make the work order's step list a copy with the task list version stamped on it.

Copying is the right default because an auditor asks what the instruction said on the day, not what it says now. Referencing the live task list rewrites history every time somebody fixes a typo.

The completion record is what moves the plan

The fourth object is treated as a formality, and it is the one that advances the schedule.

Completion writes last_done_date and last_done_meter back to the plan, and that write-back is what produces the next due point.

Miss it and the plan never advances, so a job done in the field stays overdue forever.

The PM plan record

These are the fields a plan needs before it can raise anything, in the names most systems use.

Two fields are derived and must never be editable: next_due_date and next_due_meter. A typed due date is a silent override that survives every later change to the interval.

One field carries the whole calculation: schedule_mode. It decides whether a late job pushes the next one, and it is the field most plants never notice they have.

The plan points at one asset. For which level of the tree that should be, see our asset hierarchy data model, and for the surrounding tables see the CMMS data model.

The four trigger types

Every preventive task fires on one of four things: a date, a counter, a cycle count, or a measured condition. Choosing the wrong one over-maintains half your plant and under-maintains the other half.

1. Calendar

The simplest trigger, and the right one whenever wear is driven by time rather than use.

It needs four fields: interval_value, interval_uom in days or weeks, last_done_date and lead_time in days. No meter, no conversion.

Use it for rubber and grease ageing, statutory inspections, calibration, seasonal work and anything a regulator or a customer dates.

The failure mode is an asset whose use varies. A machine running 20 hours a week and one running 120 hours a week get the same 90 day service, so one is over-serviced and the other is late.

An interval of 28 days keeps the same weekday and 30 days does not, so use multiples of 7 when the job needs a specific crew on a specific shift.

2. Meter or operating hours

The right trigger for wear driven by running: bearings, belts, filters, oil, drives.

It needs meter_id, interval_value in meter units, last_done_meter, and a rolling average daily usage to convert the lead time.

A lead time of 7 days means nothing to a counter, so it has to be turned into hours before the job can appear on anybody's list.

Take plan PM‑2118 on filler FIL‑01, interval 500 run hours, last done at 13,000 h.

• next_due_meter = 13,000 + 500 = 13,500 h.
• Average daily usage over the last 90 days = (13,480 minus 12,490) ÷ 90 = 11.0 h per day.
• Lead in meter units = 7 days × 11.0 = 77 run hours.
• So the work order is raised at 13,500 minus 77 = 13,423 h.
• At today's reading of 13,480 h the job is 20 hours from due, which is 20 ÷ 11.0 = 1.8 days.

Store the averaging window with the plan, because a 7 day window and a 90 day window give very different dates.

The failure mode is a standby asset. A spare pump that runs 40 hours a year never reaches its meter due point, so a meter only plan stays quiet while the seals dry out and the casing corrodes.

The fix is a second trigger, whichever comes first: 500 run hours or 12 months. Any plan on an intermittently used asset needs that calendar backstop.

3. Cycles or strokes

Moulds, dies, presses, punches, welding guns and pneumatic actuators wear per operation, not per hour. A press standing idle with the tool mounted burns hours and no tool life.

It needs the same fields as the meter trigger, with one difference that catches almost everybody: the cycle meter belongs to the tool, not to the machine.

Mould MOLD‑07 moves between three presses. The press shot counter counts every shot the press makes, including shots made with a different tool in it.

So the model needs a mount event, and the tool's life is the sum of its deltas.

Plan PM‑3304 on MOLD‑07 has an interval of 250,000 cycles and was last done at 1,750,000, so it is due at 2,000,000.

• Average use over the last 60 days = 8,400 cycles per day.
• Lead in cycles = 10 days × 8,400 = 84,000, so the job is raised at 1,916,000.
• At today's count of 1,910,000 the raise point is 6,000 cycles away, which is 0.7 days.
• Due is 90,000 cycles away, which is 90,000 ÷ 8,400 = 10.7 days.

The failure mode here is counting the press instead of the tool: the tool you just mounted looks worn out while the one on the rack looks new.

4. Condition or inspection result

The trigger fires when a measured value crosses a limit: vibration, temperature, oil particle count, wall thickness, current draw.

It needs a source, a measured field, a limit and a direction, plus the task list to run when it fires (see condition based maintenance).

The readings come from two places: a sensor or monitoring feed, or a step on an inspection checklist that a person fills in.

The second path is the one the model usually forgets. If the reading only exists as a checklist answer, the condition plan depends on a calendar inspection plan running first.

The failure mode is a plan with no reading source. It never fires, it never shows up as overdue, and it looks perfectly healthy on the plan list for years.

Guard it with a staleness rule: if the newest reading for the plan is older than the inspection interval, raise the plan as overdue on missing data rather than treating silence as a pass.

Floating versus fixed scheduling

Floating calculates the next due point from the last completion. Fixed calculates it from the original grid, whatever the completion date was.

Both are defensible, and a plant needs both. What breaks plants is not knowing which one a plan uses.

Take a 30 day plan first due on 2026-03-04, where cycle 1 is completed 9 days late on 2026-03-13 and every later cycle is done on its due date.

The 9 day gap never closes. It is carried forward for the life of the plan, because floating re-anchors on every completion.

Count the occurrences in the 365 days from 2026-03-04.

• Fixed grid: 13 occurrences, from 2026-03-04 to 2027-02-27.
• Floating with that one 9 day slip: 12 occurrences.
• Floating with a 9 day slip every cycle: 10 occurrences, three services a year fewer.

Nobody decided to cut three services. The plan did it quietly, one late job at a time.

The same effect on a meter plan

Meter plans float by default, and PM‑2118 shows why that matters. It is due at 13,500 h but the technician gets to it at 13,562 h.

• Floating: last_done_meter = 13,562, so the next due point is 14,062 h.
• Fixed: the grid stays on multiples of 500 from the origin, so the next due point is 14,000 h.
• The 62 hour drift repeats on every cycle, so after ten cycles a floating plan has lost more than one whole service.

Write the real reading into last_done_meter, never the due value, because setting it to 13,500 hides the drift instead of removing it.

Which mode for which work

The rule of thumb: if being late is a scheduling inconvenience, float it. If being late is a breach, fix it.

Compliance and calendar anchored work

Some plans exist because a regulator, an insurer or a customer says so. Pressure vessels, lifting gear, safety interlock checks, calibration of test equipment and hygiene verification all sit here.

These must be fixed grid, anchored to the certificate or the approval date, and never floated from the last completion.

The reason is arithmetic. A 12 month statutory interval floated from a completion two weeks late becomes a 12 month and 14 day interval, and the certificate has already expired by the time the job is raised.

Three extra fields carry the obligation on the plan.

Keep the completion record, the readings, the person, their qualification at the time and any certificate file, with a retention longer than the asset's life.

That rules out three habits: deleting old work orders to tidy the list, overwriting a completion, and editing a task list without a version.

The task list

The task list is the instruction template. One task list serves every asset of the same class, which is why the steps name components rather than tags.

Then the steps. This is where a checklist becomes data instead of paper.

The parts on the steps add up to the kit, so a storeman can pick a job before the technician arrives.

It also feeds the reorder point: a plan due 12 times a year with 6 seals per visit is 72 predictable seals of demand.

Why free text answers cannot be analysed

A checklist that asks "bearing temperature OK?" and accepts a sentence produces a pile of words. One that asks for a number in °C produces a series.

Keep a free text note field beside the typed answer, because technicians see things no field anticipated. Just never let the note be the only place the value lives.

The same argument applies to stop reasons on the production side (downtime reason code design).

Generation rules

The generator turns plans into work orders. Six rules keep it from flooding the list or going quiet.

The duplicate key is the one to insist on. A unique constraint on plan_id plus the occurrence due point stops a generator that runs twice from producing two identical jobs.

Without it, a retry after a timeout quietly doubles a month of preventive work, and nobody can tell the copies apart.

What happens when the next one falls due and the old one is still open

• Suppress. No second work order, the plan goes overdue, and one missed occurrence row is written. Right for almost everything.
• Stack. A second work order appears, and two technicians eventually do the same job twice.
• Roll forward. The open job's due date is moved to the new one, which erases the evidence that anything was ever late.

Roll forward is the dangerous one, because it makes compliance look perfect by construction. If your due dates never go red, check whether the system is rolling them forward.

Raise a year of work and the list becomes wallpaper. Raise nothing until the due date and nobody can order a part or book a shutdown.

Lead time plus the part lead time is a sane default, so a plan needing a seal with a 12 day supplier lead needs at least 12 days of notice (see unplanned downtime).

Worked example: coverage and schedule compliance

One plant, 120 maintenance assets, March 2026. Every number below reconciles with the ones above it.

1. PM coverage

PM coverage is the share of assets carrying at least one active plan. Count assets, not plans, or six plans on one filler will hide a machine with none.

Total coverage is 23 + 34 + 29 = 86, and 86 ÷ 120 = 71.7%.

The headline figure is the least useful line in the table. The one that matters is the single class A asset with no plan at all, which a 71.7% number buries completely.

Those 86 assets carry 214 active plans, an average of 2.5 per covered asset.

2. Schedule compliance

Schedule compliance is completed on time divided by due in the period. On time means completed on or before next_due_date plus grace_days, and grace here is 3 days.

148 PM work orders had a due date in March 2026.

The rows add up: 96 + 31 + 12 + 9 = 148.

• Schedule compliance = 96 ÷ 148 = 64.9%.
• Completion rate (on time or late) = 127 ÷ 148 = 85.8%.
• The 20.9 point gap between them is the plant's lateness, and reporting only the second number hides it.

3. The denominator trap

Now suppose the 9 skipped jobs are deleted from the list instead of being kept with a status. Nothing about the plant changed, and only the denominator did.

Deleting the skipped jobs is worth 4.2 points. Dropping the still open ones as well is worth 10.7 points.

The same 96 jobs were done in all three cases. The only thing that improved was the reporting.

This is why skipped is a status and never a delete. A skipped row with a reason is the single most valuable record in a preventive maintenance history, because it is the only evidence that the plan asked and the plant said no.

Print the numerator and the denominator on the report, always. A compliance percentage with no counts beside it cannot be checked, the same discipline our OEE calculation guide applies to availability.

Five questions to ask a vendor

Ask for a demonstration in their system rather than a yes.

1. Show me the plan and the work order as two records. Add a step to a generated work order, then generate next month's job and show me whether the step is there.
2. Can one plan carry two triggers, whichever comes first? Set 500 run hours or 12 months on one plan and show the due list.
3. Is scheduling floating or fixed, and is it set per plan? Complete one job nine days late, then rerun the due list and read the next four dates aloud.
4. Where does a skipped occurrence live, and what does compliance count? Ask for the exact numerator and denominator, in writing.
5. Are checklist answers typed values with tolerances? Ask them to export twelve months of one step's readings as numbers, not as a screenshot.

Before a shortlist, read what is a CMMS and equipment maintenance software. For the orders that make product rather than fix machines, see the production work order data model.

How Fabrico helps

Fabrico is an OEE platform with a full CMMS built in, and the working core of this model is in it.

Preventive plans use recurring templates and conditional tasks, and they run on a calendar with an annual plan view.

Generated work orders go through approvals, shifts and assignment, with push, in-app and email notifications when something falls due or goes late.

Technicians work from the iOS, Android or web app and scan a QR code on the machine or the part to open the right card. Inventory holds min and max levels, and consumption is booked against the work order.

What it does not do: your team creates and confirms the work, failure forecasting is not a standard feature, and there is no production planning. The deeper reference material here, such as tool mount events and versioned task lists, is a specification to compare against rather than a feature list.

Want your PM plans and machine data in one place? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.