📋Work Orders
Work orders are the unit of work in Myncel. Every repair, inspection, PM task, and safety job is tracked as a work order. This chapter covers creating, assigning, completing, reporting on, and approving them.
How work orders are created
Work orders enter Myncel three ways. Knowing which path fired a work order helps you interpret reports later (e.g. "what percentage of our work is reactive vs planned?").
- Manually — by anyone with permission, from the Work Orders tab, the equipment page, or the mobile app. Most reactive / corrective work starts here.
- From a schedule — a preventive-maintenance schedule fires automatically on its trigger (calendar, runtime, cycles, or condition) and creates a work order ready for assignment.
- From an alert — a sensor threshold breach, AI predictive event, or operator-reported anomaly auto-creates a work order. You can configure each alert to either auto-create or just notify.
Creating a work order step by step
The only required fields are equipment and title. Everything else is optional and can be filled in later, including by a different user.
- Click Work Orders in the sidebar (or "+ Work Order" on any equipment page).
- Click "+ Create Work Order".
- Pick the machine the work is for.
- Choose a type — Corrective, Preventive, Inspection, Safety, or Project. The type affects which reports the work order rolls up into and what compliance evidence is captured.
- Set a priority — Low, Medium, High, or Critical. Critical bypasses quiet hours and pages on-call where configured.
- Write a clear title (e.g. "Replace mist collector filter, MILL-A-03") and a description with relevant context.
- Assign to a specific technician, leave unassigned for the team to claim, or assign to a vendor with email auto-notification.
- Set a due date and (optionally) an estimated labor time and parts list.
- Attach photos, manuals, or any other documents.
- Click Create. The assignee is notified via their preferred channel (push, email, SMS, Slack).
Work order statuses and lifecycle
Every work order moves through a defined lifecycle. The status drives dashboards, alerts, and what fields the user can edit. Statuses are intentionally few — Myncel does not believe in twenty-step workflows.
- Open — created but no one has started yet. Counts toward backlog.
- In Progress — a technician has accepted and is actively working. The clock is running for MTTR.
- On Hold — paused, with a required reason (Waiting for Parts, Waiting for Vendor, Waiting for Approval, Production Conflict, Other). MTTR clock pauses.
- Completed — work is done and the completion form has been filled in. Locked from further edits except by managers.
- Cancelled — closed without being executed. Requires a reason; counts in reports separately from completed work.
Completing a work order
When a technician finishes a job they should mark the work order Completed and fill in the completion form. The form captures actual labor time, parts consumed, what was done, root cause (for corrective work), and any follow-up work needed.
On the mobile app the completion form is the same form, optimized for thumbs — large tap targets, voice-to-text on text fields, camera button for photos, and signature pad if a sign-off is required.
Encourage technicians to attach at least one photo of the completed repair. Photos make audits, warranty claims, and root-cause analysis dramatically easier later, and they take five seconds to capture.
Assignment, queuing, and dispatch
Three assignment patterns are supported, and you can mix them across teams.
- Direct assignment — the supervisor picks the technician. Best for small teams or when a specific skill is required.
- Self-claim queue — work orders are created unassigned. Technicians see them in a shared queue and tap "Claim" to take ownership. Best for cross-trained teams that want to balance load themselves.
- Auto-assignment — Myncel matches the work order to a technician using configurable rules (skill tags, location, current load, certification). Available on the Professional plan.
Approval workflows
Myncel ships a multi-step approval engine that gates work-order transitions. Each approval policy targets a specific trigger — pre-start (when someone tries to move a WO to IN_PROGRESS), pre-close (when someone tries to mark it COMPLETED), or vendor quote (a logical channel for committing high-cost parts) — and matches against priority, work-order type, and minimum total cost. When a matching transition is attempted, the work order is parked in a new PENDING_APPROVAL status and an approval request is opened with one ordered step per policy step. Each step names either a permission gate (e.g. work_orders.approve_budget) or an explicit list of named approver users, and can be configured to require any one approver or every named approver.
Approvers see a queue at /approvals (sidebar → Approvals) showing every request waiting on them, with full work-order context, the current step name, and Approve / Reject buttons. Approving the final step automatically applies the original requested transition — moving the WO to IN_PROGRESS or COMPLETED and stamping startedAt / completedAt — while rejection at any step rolls the WO back to its previous status and captures the rejecter's comment in the audit trail. Every decision is timestamped, attributed to a specific user, and stored permanently. Approvers receive an email the moment a step opens up, with a one-click "Review work order" button.
Owners and admins manage policies at Settings → Approvals (/settings/approvals). They can pause a policy without deleting it, edit thresholds, reorder steps, and add or remove named approvers without affecting requests already in flight. Users holding the work_orders.manage_approvals permission can also bypass any approval by appending ?bypass=1 to the work-order PATCH call (intended for break-glass automation, audited via the standard work-order log). The number of pending approvals is visible in your /approvals queue badge so nothing falls through the cracks.
- Three trigger types — pre-start budget approval, pre-close safety sign-off, vendor quote approval.
- Match by any combination of priority (CRITICAL / HIGH / MEDIUM / LOW), work-order type (PREVENTIVE / CORRECTIVE / EMERGENCY / INSPECTION / PROJECT), and minimum total cost (parts + labor in the org's currency).
- Up to 10 ordered steps per policy. Each step uses a permission gate, a named-user list, or both.
- requireAll flag per step — first approver advances by default, or require every named approver to sign off.
- Email notifications to all eligible approvers when a step opens; final-state email to the requester.
- Full audit trail — every approval and rejection is timestamped with attribution and an optional comment.
- Bypass via work_orders.manage_approvals + ?bypass=1 query param for break-glass scenarios.
Setting up your first approval policy
A practical example: require the maintenance supervisor to sign off on any EMERGENCY-type work order before it can be closed. Open Settings → Approvals, click "+ New policy", and fill in the editor:
- Name: "Emergency WO close-out sign-off".
- Trigger: "Pre-close safety sign-off" (fires on the OPEN/IN_PROGRESS → COMPLETED transition).
- Match priorities: leave empty (any priority).
- Match types: select EMERGENCY only.
- Minimum total cost: 0 (any cost).
- Step 1: name "Supervisor sign-off", required permission "work_orders.approve_safety", requireAll unchecked. Anyone in the org with that permission can sign off.
- Click Create policy. The policy is active immediately. The next time anyone tries to mark an EMERGENCY work order COMPLETED, Myncel parks it in PENDING_APPROVAL and emails everyone with work_orders.approve_safety.
Build a tier ladder by stacking multiple policies on the same trigger with different minTotalCost values. The most expensive matching policy wins, so you can require one supervisor under $5k, two supervisors $5k–$25k, and the plant manager above $25k — all on a single PRE_CLOSE trigger.
Parts, labor, and cost capture
Each work order tracks estimated and actual minutes, labor cost, parts cost, and total cost in your chosen currency. Parts can be selected from your stocked-parts catalog (which auto-decrements stock) or entered as ad-hoc one-offs. Labor is recorded by entering actual minutes when you complete the work order — start/stop timers are on the roadmap.
Total cost rolls up automatically from parts cost + labor cost and shows on the work-order page and in the Reports section. Currency is per-work-order so multi-region organizations can keep clean accounting.
Recurring work orders — using Schedules
Recurring work in Myncel is handled by Schedules (the Schedules tab in your sidebar, or /admin/schedules). Create a Maintenance Schedule with a Title, Task Type (PREVENTIVE / PREDICTIVE / CORRECTIVE / INSPECTION), Priority, Frequency (DAILY / WEEKLY / BIWEEKLY / MONTHLY / QUARTERLY / BIANNUAL / ANNUAL / CUSTOM / BY_HOURS), and target machine. Whenever the schedule falls due, Myncel auto-generates a work order against the machine and assigns it to the responsible technician.
Use BY_HOURS for runtime-driven PMs (e.g. "every 500 spindle-on hours") when you have a runtime feed from the Edge Gateway. Use CUSTOM with an interval-in-days field for non-standard cadences. The schedule's next due date and last completed date are visible on the schedule list and update automatically as work orders are completed.
- Reusable, standalone Work Order Templates (separate from a recurring schedule) are on the roadmap.