> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # How plans raise work > From a plan's triggers to rounds, work orders and inspection rounds — lead time, tolerance, meter and condition triggers, stand-downs and versions. This page follows what happens after a [maintenance plan](/maintenance/plans) is activated: how its triggers become rounds, how rounds become work orders or inspection rounds, and how each is judged on time or late. ## Plans, rounds and work | Word | What it is | | - | - | | **Plan** | The rule: what to do, to which assets or places, and what makes it fall due. | | **Round** | One scheduled visit produced by a plan — one asset (or one place), one due date. A plan covering six conveyors on a monthly trigger produces six rounds a month. Rounds are what [Maintenance Due](/work/maintenance-due) lists, and what the plan's [Rounds tab](/maintenance/plan-detail#rounds) shows. | | **Work order** | The job a round becomes, for a plan whose type raises work orders. It carries the plan's checklist and requirements. | | **Inspection round** | What a round becomes for a plan whose type raises an inspection — a graded checklist from an [inspection template](/maintenance/inspections), with no work order beside it. | ## Step by step Activating publishes version 1 of the plan and builds its schedule straight away. A plan with nothing in scope or no trigger cannot be activated — the builder's Preview step says what is missing. For **calendar** triggers, rounds are created for every asset in scope across your organisation's planning horizon — 90 days unless your administrator has changed **Planning horizon (days)** under [organisation settings](/setup/organisation). The schedule is topped up automatically as time moves on, and a planner can top it up at once with **Generate now** on Maintenance Due. **Meter** and **condition** triggers do not predict dates. Their rounds are raised the moment the reading or condition says so — see below. A plan's **lead time** is how many days before the due date its work should appear. When a round enters that window: * if the plan has **Raise the work order automatically** switched on, its work order is raised by itself (or, for an inspection plan, its inspection round is raised); * if it is switched off, the round waits on Maintenance Due for a planner to raise it by hand — the choice for plans gated on readiness or capacity. A plan with no lead time raises its work on the due date itself. The work order is worked and closed like any other, or the inspection round is answered and submitted. Submitting an inspection round completes the round that asked for it. A **fixed-calendar** trigger keeps its dates whatever happens. A trigger set to **count from completion** places the next round one interval after the last one was finished, so a late round moves the ones after it. ## What a work order takes from its plan When a round's work order is raised, it copies from the plan as it stands at that moment: | From the plan | On the work order | | - | - | | Type and priority | The work order's type and priority, and the service level that priority carries | | The checklist | The task list, section by section, with mandatory steps, readings and evidence | | Parts, tools, skills and vendors | [Requirements](/work/work-order-detail), which the readiness check reads before anybody is sent | | Crew, preferred worker or preferred vendor | Who the job is handed to — the crew first, then the worker, then the vendor | | Permit requirement, safety instructions and work instructions | The same on the job, so a permit shows on readiness and the instructions are read before work starts | | Response and resolution targets | The job's deadline, counted from the round's scheduled date; without them the deadline comes from your organisation's service levels | Editing the plan later changes rounds not yet raised. Work orders already raised keep what they were raised with, because a job somebody is part-way through should not change under them. Where the plan names an inspection template but its type is an ordinary work order type, each round raises the work order **and** an inspection round beside it. The work order is still what somebody is scheduled and held to a due date for. ## Meter triggers A meter trigger names a **meter type** — running hours, cycles, kilometres — rather than one meter, so every asset in scope that carries a meter of that type is watched separately. When a new reading on an asset passes the last value that asset fired at plus the interval, a round is raised for that asset. A reading that jumps more than one interval raises **one** round, not several: 1,600 hours against a 500-hour interval raises one round and the next falls due at 2,000. Readings are recorded on the asset's [meters](/assets/meters), including from [the field app](/field/readings). ## Condition triggers A condition trigger is a rule about the asset — a meter's latest reading above a limit, a health score below a threshold, a field with a particular value. It is checked against the asset as it stands, and only on the **rising edge**: a round is raised when the condition becomes true, and not again until that round is finished. Readings re-check conditions immediately; everything else is checked on a regular pass. ## When triggers combine A plan with more than one trigger combines them with its **trigger rule**: | Rule | Falls due when | | - | - | | **Any of them (or)** | The first trigger fires — *every 90 days or every 2,000 running hours, whichever comes first*. The usual choice. | | **All of them (and)** | Every trigger has fired. | ## Lead time, tolerance and compliance | Term | Set on | What it decides | | - | - | - | | **Lead time (days)** | The builder's Scheduling step | How far ahead the work order (or inspection round) appears, so parts can be gathered and the work planned into somebody's week. | | **Tolerance (days)** | The builder's Scheduling step | How late is still on time. Beyond this, PM compliance counts the round as missed. It is also the work order's resolution deadline unless the plan sets a resolution target. | The builder's Preview step shows both for the plan's first round, for example *3 days · on time until Oct 22, 2026*. ## Plans that cover other plans Some plans include everything another plan does — an annual service that includes the monthly round. On the builder's Scheduling step the annual plan can **stand down** the monthly one. In a month that gets the annual round, the monthly round is still recorded but marked **Skipped**, covered by the annual one, and it does not count against PM compliance. If the covering round is later cancelled, the stood-down round is put back. By default "the same month" counts as covering. A window in days can be given instead, for plans whose round comes more often than monthly. ## Round statuses Rounds have their own state model. The defaults are below, and your administrator can rename or extend them under [statuses](/config/statuses). | Status | Means | | - | - | | **Planned** | On the schedule, not yet within its lead time. | | **Due** | Within its lead time; work should be raised. | | **Work Order Generated** | Its work order (or inspection round) exists. | | **Completed** | The work is finished. | | **Skipped** | Deliberately not done — skipped with a reason on Maintenance Due, or stood down by a plan that covers it. | | **Deferred** | Moved to a later date, with a reason. | | **Cancelled** | Withdrawn. | Skipping, deferring and raising early are done from [Maintenance Due](/work/maintenance-due), which also offers a calendar view of what is coming. ## Versions Every round records the version of the plan it was raised under. If a plan is edited after it was last published, new rounds follow the edits straight away but still carry the old version number — the plan's screen warns about this, and **Publish version N** puts the change on the record. See [Publishing a new version](/maintenance/plan-detail#publishing-a-new-version). Where rounds are raised, deferred and skipped. What an inspection round is and how it is graded. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.