---
title: "Overview: maintenance management"
description: "Maintain is the IoTFlows CMMS, and a work order is its only object: a request, a planned job and a preventive maintenance schedule are all the same record with different fields filled in. Work orders arrive from five places, from the board itself, a classified downtime, a machine event rule, a meter reaching its trigger point, or the Maintenance panel in the job runner. They move through Open, In Progress, On Hold, Done and Approved, and closing one moves stock in Inventory."
category: "Start here"
source_url: "https://www.iotflows.com/docs/maintain/overview/"
---
# Overview: maintenance management

What Maintain tracks, and how it connects to machines, production and stock.

Maintain is the IoTFlows *CMMS*, a computerized maintenance management system: the one place maintenance work is asked for, planned, done and recorded. It sits at `/<organization>/maintenance` on the web and ships as a native screen in the iOS and Android apps. Nothing needs setting up before you open it. Getting the rest of your maintenance team onto the board is on [Give people access to Maintain](/docs/maintain/board-members/).

## What a work order is here
A *work order* is one maintenance job: a title, a machine, a priority, a due date, the people doing it, and the parts it will use. It is the only object Maintain has. A request an operator files from a phone, a job a planner writes out field by field, and a quarterly lubrication schedule are the same record with different fields filled in.

Diagram: A diagram in two bands. The top band, headed where a work order comes from, holds five boxes side by side: The board, you fill it in, on the web or a phone; A downtime, classify a stop, then create one from it; A machine event, a rule's Work Order switch, automatic; A meter, automatic, when it reaches its trigger; A job on the floor, the Maintenance panel in the runner. An arrow drops from each of the five onto one horizontal line, and a single arrow runs from that line down into the first box of the second band. The second band, headed the statuses it moves through, runs left to right: Open, filed, nobody is on it; then start work; In Progress, somebody is working it; then complete; Done, the work is finished; then approve; Approved, signed off. A two-way arrow hangs below In Progress to a fifth box, On Hold, blocked or waiting, labeled on hold going down and resume coming back. An arrow drops from Done to a note reading: closing consumes the parts it required and adds the parts it created. A line across the bottom reads: a preventive maintenance job is one of these, with a recurrence rule on it.

*The work-order state machine, and the five places a work order can come from.*

Every work order carries one of five statuses: **Open**, **In Progress**, **On Hold**, **Done** and **Approved**. What each one means, and every field behind it, is on [Work order fields and statuses](/docs/maintain/work-order-fields/).

There is no separate preventive-maintenance object. A *PM* is a work order with a recurrence rule on it, so anything you can do to a work order you can do to a PM: reassign it, attach a photograph, change its parts list. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/).

### Where work orders come from
| Origin | Creates | Page |
|---|---|---|
| The maintenance board, on the web or a phone | A work order you fill in yourself | [Create a maintenance work order](/docs/maintain/create-a-work-order/) |
| Classifying a machine stop | A work order prefilled with that machine and the downtime category as its title | [Classify a downtime](/docs/monitoring/classify-downtime/#work-order) |
| A machine event rule with its **Work Order** column switched on | A work order automatically, unassigned, each time that event fires on that machine | [Set up machine event rules](/docs/alerts/asset-event-rules/#work-order) |
| A meter reaching its trigger point, with **Create Work Order when triggered** checked | A work order automatically, on runtime hours, a calendar interval or a parts count | [Trigger maintenance from meter readings](/docs/maintain/meters/) |
| The **Maintenance** panel in the job runner | A work order prefilled with the machine the operator is running | [Run a job](/docs/production/run-a-job/#maintenance) |

Every entry point an operator can reach, web and mobile, is collected on [Submit a maintenance request](/docs/maintain/submit-a-request/).

## The board and the drawer
Maintain is one board per organization, and everything filed lands on it. You cannot split maintenance across several boards the way the Scheduler splits production.

The board offers four views of the same work orders: **List**, **Table**, **Kanban** and **Calendar**. Filters narrow them by completion status, machine, group and people, where a *group* is a named, colored bucket you define on the board, for example `Electrical` or `Weekly PMs`. See [Organize work on the maintenance board](/docs/maintain/maintenance-board/).

Selecting a work order opens it in a drawer beside the board, so the list stays in view. The drawer is where the work happens: change status, edit any field inline, tick off a checklist, attach photographs and files, and talk to the assignees in a comments thread. See [Update, discuss, and close a work order](/docs/maintain/work-order-detail/).

## How Maintain connects to the rest of IoTFlows
**Machines.** A work order points at an asset, so a machine's maintenance history is the work orders that named it. The stops and events behind them come from [Monitoring](/docs/monitoring/overview/).

**Alerts.** A machine event rule can open a work order instead of, or as well as, emailing somebody. The rule carries no assignee, so an automatic work order arrives unassigned and somebody has to triage it.

**Production.** An operator raises a request without leaving the job runner, and the job keeps running while they do. Production work itself is scheduled separately, on the [Scheduler](/docs/production/scheduler/).

**Inventory.** A work order has two parts lists: what it requires and what it creates. Moving it to **Done** deducts the first from stock, adds the second, and writes the inventory transactions, after asking you to confirm. See [How work orders move stock](/docs/inventory/how-work-orders-move-stock/).

## What Maintain does not do
**It does not schedule production.** A maintenance work order and a production task are different objects on different boards, and blocking a machine for maintenance does not take it out of the production schedule.

**It does not classify downtime.** Opening a work order from the **Classify Downtime** modal and saving the reason are two separate actions in the same modal: doing one does not do the other.

**It does not hold the parts catalog.** A work order references parts that already exist in Inventory. Creating a part is an Inventory task.

**You probably do not need meters** if your maintenance is date-driven. A recurrence rule already covers "every 90 days". Reach for a meter only when the interval depends on how hard the machine ran, for example 500 spindle hours rather than three months.

## Where to start
New to Maintain: run one work order end to end with [Quickstart: create and close your first work order](/docs/maintain/quickstart/), which touches the board, the drawer and the status flow.

Setting Maintain up for a team: put your maintenance people [on the board](/docs/maintain/board-members/) first, then check what each organization role can do in [Roles reference](/docs/admin/roles-reference/).

## See also
- [Quickstart: create and close your first work order](/docs/maintain/quickstart/)
- [Create a maintenance work order](/docs/maintain/create-a-work-order/)
- [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/)
- [How work orders move stock](/docs/inventory/how-work-orders-move-stock/)