Practical evaluation guide · Updated 7 September 2026
In this guide
Start with the asset register
Import your assets first. Each schedule row refers to an existing asset_code in your workspace. A retired asset or an inactive site cannot receive an imported schedule. Use a different name for each distinct schedule on an asset. The importer rejects duplicate asset/name pairs instead of overwriting existing maintenance.
Use the calendar fields
Keep the template headers in their original order. Set trigger_type to calendar, frequency_value to a whole number from 1 to 3650, and frequency_unit to days, weeks, months or years. Supply next_due_date as YYYY-MM-DD. It is interpreted as 09:00 in your workspace timezone and stored in UTC. Leave meter_interval and next_meter_value empty. Set lead_days from 0 to 90 and priority to low, medium, high or critical.
Use the meter fields
For trigger_type meter, the asset must already have a configured meter. Supply a positive meter_interval and an explicit next_meter_value in that asset’s meter unit. The next value is an absolute reading, not the distance remaining. A threshold already reached may produce due work after you resume the schedule. Keep frequency_value and frequency_unit populated for the required record fields; they do not turn a meter schedule into a calendar trigger.
Preview and review before activation
Upload at most 500 rows in a CSV file up to 1 MB. The preview is available for 30 minutes and is bound to your signed-in user and workspace. Resolve all errors before import. The workspace is revalidated at commit; no schedules are created if any row is invalid. Imported schedules are paused and unassigned, with no procedure attached. Review each plan, attach its approved procedure and owner, then resume it deliberately.
Decide what deserves a recurring schedule
A maintenance schedule import is a way to transfer approved recurring work into a controlled system. It is also an opportunity to remove ambiguity before that ambiguity becomes a queue of jobs. A spreadsheet row saying “service pump monthly” leaves several decisions unresolved: which pump, what service, whose procedure, which starting date and who will respond when the work becomes due? Importing those words successfully does not answer those questions.

AI-generated editorial illustration; not a customer photograph or product screenshot.
Separate your source workbook into assets, recurring plans and completed history before mapping columns. An asset identifies the equipment. A plan defines a repeated obligation. A completed work record describes something that already happened. Copying completed service rows into the schedule importer would create future obligations from historical events. Use the work-order history import guide for completed records and the asset migration guide for equipment identities.
Choose a small first batch that includes the real variation in your operation. Ten similar weekly checks will test less than a mixed sample containing a monthly inspection, a meter service, two assets at different sites and an intentionally invalid row. Your objective is to prove the mapping and review process before multiplying it. Keep an unchanged copy of the original workbook so reviewers can explain how each imported decision was made.
Build a field map before editing the CSV
Use the downloadable schedule template as the destination contract. The importer expects ten columns in the original order, including columns that are empty for a particular trigger. Do not remove a calendar column just because every plan in the current file uses a meter. Similarly, do not add a technician-name column expecting the importer to assign that technician. Ownership and procedures are reviewed after import.

AI-generated editorial illustration; not a customer photograph or product screenshot.
| CSV field | Meaning | Preparation check |
|---|---|---|
| asset_code | Existing equipment identity | Match the destination register, not a nickname |
| name | Distinct plan name on that asset | Explain the scope without embedding a changing date |
| trigger_type | calendar or meter | Choose the actual trigger, not the workbook tab name |
| frequency_value | Required whole-number frequency | Use 1–3650 |
| frequency_unit | days, weeks, months or years | Use the exact supported value |
| next_due_date | Next calendar deadline | Use YYYY-MM-DD for calendar plans |
| meter_interval | Repeating usage interval | Use the configured asset meter unit |
| next_meter_value | Absolute next usage threshold | Do not enter remaining usage |
| lead_days | Advance planning window | Use a whole number from 0–90 |
| priority | low, medium, high or critical | Apply a consistent local priority policy |
Create a separate mapping worksheet if the original source uses different labels. For example, a source field called “PM cycle” may contain mixed values such as monthly, 30 days and every 500 hours. These are different scheduling decisions. Translate them into explicit fields with a reviewer, rather than using a global find-and-replace that treats them as equivalent.
Work through a calendar example
Consider an illustrative air-compressor inspection due on 2026-10-01, repeating monthly. The asset already exists as COMP-014 at an active site. A suitable name might be “Monthly condition inspection.” The row uses calendar, frequency value 1, frequency unit months and the next due date 2026-10-01. Meter interval and next meter value remain empty. A lead window of seven days and medium priority could be reasonable planning choices if they match the team’s approved process; they are examples, not universal maintenance recommendations.

AI-generated editorial illustration; not a customer photograph or product screenshot.
The deadline is interpreted at 09:00 in the workspace timezone before being stored in UTC. Confirm the organization timezone before preparing dates, especially when migrating from a system that exported timestamps in another region. A plain date such as October 1 does not contain timezone information. The destination therefore needs a deliberate interpretation rather than silently inheriting the timezone of the person editing Excel.
Do not replace monthly with thirty days unless the maintenance owner approves that change. Calendar months have different lengths. A plan intended for a fixed monthly routine expresses a different obligation from one intended to repeat every thirty days. The import should preserve the approved maintenance strategy, not normalize every interval into whichever unit is easiest to calculate in a spreadsheet.
After import, the plan remains paused. Open it, confirm its timing, attach the approved procedure and decide who owns execution. Review what will happen when it is resumed, particularly if the starting date is already in the past. The import itself is not evidence that an overdue inspection has been carried out.
Work through a meter example
Imagine a pump with a configured operating-hours meter currently reading 1,240 hours. Its approved service interval is 250 hours, with the next service due at an absolute reading of 1,500 hours. The import row uses meter as the trigger, 250 as meter_interval and 1500 as next_meter_value. Entering 260 because that is the remaining usage would set the threshold far below the current reading. That error could make work immediately due when the plan is resumed.
The required frequency value and unit still need valid values in the record. They do not create a second calendar trigger on a meter plan. If the source describes “every 250 hours or every six months, whichever comes first,” do not claim that a single imported meter row represents both conditions. Review how the organization wants to model the separate obligations and avoid creating duplicate work without a clear operating rule.
Confirm the meter unit on the asset before preparing the row. Kilometres, miles and operating hours are not interchangeable. An imported number does not carry a unit label that overrides the configured asset meter. If your fleet source uses miles while the destination asset uses kilometres, resolve that mapping deliberately and keep the conversion evidence with the migration worksheet.
A schedule threshold also depends on trustworthy readings. A correctly imported 1,500-hour threshold cannot become useful if nobody records new usage or an integration maps the wrong equipment. Review the meter-based maintenance workflow alongside the import. Establish who reviews stale readings, replaced meters and implausible jumps before relying on usage-triggered planning.
Use names that prevent duplicate obligations
Plan names should distinguish maintenance scope on the same asset. “Monthly inspection” and “Annual service” may be legitimate separate plans. “Monthly Inspection” and “monthly inspection” are not a useful distinction. The importer checks names without case sensitivity when identifying duplicate asset-and-name pairs in the file or existing workspace.
If a duplicate is reported, investigate before renaming the incoming row. Adding “new” or a number merely to pass validation can create two plans for the same obligation. Determine whether the existing plan is correct, whether the source contains a true additional task or whether the migration batch has already been imported. The importer creates plans; it does not update existing ones through an overwrite mode.
Use stable names rather than dates in titles. “Quarterly drive inspection” is easier to recognize over time than “Drive check October 2026.” Keep the changing deadline in its date field. Include enough scope to distinguish a lubrication round from a condition inspection without turning the name into the entire procedure. The detailed task instructions belong in the approved procedure attached after import.
Diagnose file errors without losing source meaning
CSV files contain values, not workbook formulas or multiple tabs. Export the intended worksheet and reopen the result in a plain-text-aware editor or import preview. Check that the delimiter is a comma, the header sequence is unchanged and quoted descriptions have not created extra cells. Each row must contain the same number of columns as the header.
A rejected asset code usually requires a register check. The asset must exist in the current workspace, must not be retired and must belong to an active site. Do not activate a closed site or change an asset’s retirement status simply to get a file through validation. Decide whether that equipment should receive future work at all. Historical work on retired equipment belongs in the history workflow, whose rules differ intentionally.
A rejected meter trigger can indicate that the asset has no configured meter. Configure the correct meter through the asset workflow, then preview again. A rejected priority or unit usually reflects an unsupported label. Translate “urgent” to a supported priority only after agreeing what urgent means locally; otherwise a mechanical mapping can distort the planner’s queue.
Keep a short error log recording the source row, reported problem, correction and reviewer. This is particularly valuable when another person will prepare later batches. A repeatable correction rule is faster and safer than rediscovering the same formatting issue for every file.
Treat preview and commit as different decisions
Preview validates the proposed rows without creating schedules. Use that stage to compare a few records against the original workbook, including a high-priority asset and both trigger types where relevant. Confirm not just that errors are absent, but that the resulting plan meaning is right. A technically valid date can still be the wrong date.

AI-generated editorial illustration; not a customer photograph or product screenshot.
The preview is available for thirty minutes and is associated with the signed-in user and workspace. If it expires, upload and preview again. If another manager changes an asset, site or existing plan while you are reviewing, the commit step revalidates the destination state. This prevents an earlier clean preview from acting as permission to write records that have become invalid.
Commit is atomic for the batch: any invalid row prevents the schedules from being created. Do not assume the valid portion was imported when the operation reports an error. Correct the problem, generate a fresh preview and reconcile the final result. Keep batches understandable enough that a reviewer can compare expected and actual counts without relying on memory.
For a large migration, number batches in your own migration log and record the original file checksum or preserved filename, row count, operator and completion time. This log is an operational practice you maintain; it is not a claim that the importer supplies a complete migration project-management system.
Review paused plans before resuming them
Paused imports provide a deliberate checkpoint between data transfer and operational work generation. Review the asset, trigger, next deadline or meter threshold, priority and advance window. Then attach the procedure that describes the task and assign appropriate ownership. A plan without clear execution instructions can generate work that technicians interpret differently each cycle.

AI-generated editorial illustration; not a customer photograph or product screenshot.
Pay special attention to overdue starting points. Your source workbook may contain a next due date that was never updated after a completed service. Compare it with the latest trusted history before changing it. Do not move the deadline forward merely to remove a red status; record why the revised starting point is justified.
Resume a small group first and inspect the resulting due-work behavior. Confirm that the right equipment appears, the scope is recognizable and the responsible people can find the work. Explain to technicians that an imported plan is a future obligation, while completed history remains a separate record. That distinction avoids treating migration activity as maintenance completion.
Review workload capacity before activating hundreds of plans at once. If the source contains a large backlog, activation may reveal legitimate overdue work. The next step is prioritization and planning, not hiding the backlog through arbitrary dates. Use the maintenance scheduling guide to structure that review around access, parts, skills and equipment availability.
Define acceptance criteria for the first batch
A useful acceptance check covers data, behavior and ownership. For data, compare the number of imported plans with the approved source rows and sample the field values. For behavior, verify that paused plans stay paused until reviewed and that resumed plans express the intended obligation. For ownership, ask a planner and technician to explain what they will do when the work becomes due.

AI-generated editorial illustration; not a customer photograph or product screenshot.
Record any discrepancy before preparing the next batch. A meter-unit mismatch discovered after twenty records is much easier to resolve than the same mismatch replicated across five hundred assets. The purpose of a pilot is to expose such errors early, not to demonstrate that the upload button works.
After the first completed cycle, compare expected work with actual execution. Were procedures sufficient? Did parts availability cause delays? Were dates interpreted correctly? Did an owner understand the priority? Those findings improve the recurring process and should influence later imports. File validity is an entry condition; successful maintenance execution is the operational outcome.
Questions teams ask before importing schedules
Can we upload our existing workbook unchanged?
Use it as a source, then map it into the exact CSV template. Workbook formatting, formulas, extra tabs and custom columns are not transferred as schedule behavior. Preserve the original workbook separately so the mapping can be audited and corrected.
Does this import completed work or update existing plans?
No. It creates new paused recurring plans. Use the completed work-history importer for past jobs. Review existing plans through their normal management workflow rather than renaming duplicate rows to force an additional copy into the system.
What should we do immediately after a successful import?
Reconcile counts, inspect representative records, attach procedures and ownership, then resume a controlled first group. Keep the rest paused until reviewed. A successful migration leaves the team with understandable obligations and a clear next action, not merely a larger database.
How should we preserve the reason for a schedule change?
Keep the source recommendation, responsible reviewer and reason for any changed interval in the maintenance planning record or your approved supporting documentation. An import file records the selected values, but it does not explain why a monthly obligation became quarterly. That explanation matters when equipment conditions, manufacturer guidance or operating patterns change again.
During the pilot, ask a second planner to interpret the schedule without speaking to the person who prepared the file. They should be able to identify the equipment, the trigger, the next obligation and the approved task scope. If they cannot, improve the naming, procedure or supporting notes before expanding the batch. This practical handover check catches ambiguity that a file validator cannot detect.