FTMaintenance scheduling needs an effective job-plan version
FTMaintenance says teams can build a master preventive-maintenance plan, create tasks and procedures, schedule by calendar or runtime, and automatically generate work orders. Reliable execution still depends on proving which approved job-plan version applied when each order became due and was released.
Editorial figure by Maintenance Operations Ledger. Source context: FTMaintenance official CMMS record.
Bind every trigger to an effective plan version
FTMaintenance says its preventive-maintenance capability supports a master plan, tasks and procedures, and calendar- or runtime-based scheduling. It also says work orders can be generated automatically. Those statements establish documented application scope, not the condition of any customer's program. A due date or meter threshold can generate the right order at the wrong interval, against the wrong asset configuration, or with instructions that have since been superseded.
Create an effective job-plan record for each governed asset population. Include asset or class, site, operating context, criticality, maintenance strategy, trigger type, interval and unit, meter source, tolerance, seasonal or outage window, task sequence, procedure revision, permits and isolations, skill or certification, tools, parts and quantities, estimated duration, acceptance criteria, approver, effective date, superseded version, and change reason. The generated order should retain that version rather than silently inheriting later edits.
Protect the cutoff between schedule calculation and release
A schedule is recalculated as meter readings arrive, calendars change, assets enter or leave service, and prior work is completed or deferred. Preserve the cutoff, last qualifying completion, current runtime value, source timestamp, rollover or reset handling, interval calculation, grace window, and next-due result. If a late or corrected meter reading changes due status, retain both calculations and the disposition instead of overwriting the earlier record.
Keep due, generated, planned, approved, released, started, interrupted, completed, inspected, and closed as separate states. Assign each state an actor, timestamp, reason, and evidence. A generated order should not reserve labor or parts unless that is an explicit rule; a planner's release should not prove equipment isolation; technician completion should not prove the acceptance criteria passed; and closure should not erase a deferral, deviation, or follow-up defect.
Test revisions against work already in flight
Revise a torque value, safety step, inspection limit, part substitution, required trade, or runtime interval after an order has been generated. Confirm which open orders keep the old plan, which are recalled, which require planner review, and how field users see the change. Test an offline device and a printed copy so the team can prove that superseded instructions are withdrawn or visibly identified.
Also test asset exceptions. Move equipment to another site, swap a component, roll over a meter, skip a cycle during shutdown, complete work early, defer for production, and discover the wrong asset hierarchy. Inspect how the system recalculates the next due event and whether it preserves the approving owner, risk acceptance, temporary control, expiration, and corrective follow-up. The audit record should explain both the schedule and the work performed.
Use feature scope as the start of the demonstration
A buyer test should select one calendar plan, one runtime plan, and one mixed exception. Follow each from approved plan through due calculation, order generation, planning, release, field access, execution, inspection, closeout, and next-due calculation. Ask for a revised procedure, a stale mobile copy, a bad meter, a deferred job, and a failed acceptance criterion, then identify which controls are native, configured, procedural, or external.
Maintenance Operations Ledger reviewed the registered FTMaintenance page on September 7, 2026. It supports the provider's public descriptions of preventive-maintenance planning, tasks, procedures, scheduling, and automatic work-order generation. It does not establish any customer's job-plan quality, asset data, trigger accuracy, safety control, authorization, execution, inspection, reliability result, or savings, and it provides no dated post-cutoff change evidence.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Maintenance Operations Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.