CMMS Operator Workflow
This guide describes the operator workflow for FactVerse CMMS Operations. It is written for facility managers, maintenance supervisors, service coordinators, and field leads who need a common workspace for work-order review and execution.
Workflow Overview
Prerequisites
| Requirement | Why it matters |
|---|---|
| User permissions | Operators need work-order, asset, attachment, and field-execution permissions |
| Asset identity | Work orders must resolve to the intended asset or location |
| Status mapping | Provider statuses must map to the common lifecycle |
| Assignment rules | Teams need clear ownership for triage, dispatch, execution, and closeout |
| Evidence policy | Photos, reports, checklists, and closeout files need agreed handling |
| Integration mode | Operators should know whether the source is native FactVerse, read-only provider import, handoff, or write-back |
Source Data Inputs
| Input | Use |
|---|---|
| Work-order backlog | Main list of requests, assigned work, blocked work, and closeout candidates |
| Asset context | Equipment, location, history, inspections, alerts, and related documents |
| Provider status | Source-system state used for provider communication |
| Common status | FactVerse lifecycle state used for cross-provider operations |
| Assignment data | Owner, assignee, crew, provider, planned window, and escalation owner |
| Evidence files | Photos, service reports, checklists, permits, and closeout packages |
| Feedback fields | Root cause, action taken, replaced part, outcome, and follow-up recommendation |
Step 1: Review Backlog
Open CMMS Operations or Work Orders and filter by:
- site, building, or area;
- provider or source system;
- common status;
- priority and SLA;
- assigned owner or service provider;
- asset type or system;
- blocked or overdue state.
Start each shift by reviewing critical, high-priority, overdue, blocked, and newly created work.
Step 2: Triage Requests
For each request:
- Confirm the source and provider status.
- Check whether a duplicate work order already exists.
- Confirm the asset, location, and system.
- Review recent alerts, inspections, sensor signals, and related work orders.
- Set or confirm priority and SLA.
- Add triage notes and required evidence.
Work requests can come from field mobile reporting, inspection findings, natural-language intake, provider feeds, or supervisor entry. The request should carry enough context for triage: category, severity, station or asset reference, title, description, current and normal values when available, photos, voice notes, location, requester identity, and whether the request should immediately create a work order.
Typical channels include field worker reports, web portal requests, natural-language or assistant intake, alerts, and inbound email. At minimum, a request should include a title, description, severity, category when available, equipment or location reference, requester information, and any photo, voice, or location evidence. If the deployment supports immediate creation, the request may include an auto-create flag, but supervisor triage should still be visible in the audit trail.
Use these request states in operator procedures:
| State | Meaning |
|---|---|
| Reported | The request has entered the queue and needs review |
| Triaged | The request has been reviewed and is ready for conversion, rejection, or follow-up |
| Work order created | A work order has been created from the request |
| Work order skipped | The request was recorded without creating a work order |
| Rejected | The request was reviewed and rejected with a reason |
Step 3: Assign Work
Assign work according to the operating model:
| Assignment type | Use |
|---|---|
| Internal technician | Site team owns execution |
| Crew | A named maintenance crew owns the execution window |
| Contractor | External provider owns field execution |
| Downstream CMMS provider | Native provider workflow owns dispatch |
| Supervisor review | Work needs approval before dispatch |
| Data-quality owner | The record needs mapping or source correction before action |
Record planned maintenance window, access constraints, safety requirements, and required attachments before execution.
When technician and crew directories are enabled, assign work to the first-class resource and keep a clear assignee record. Technician records may include type, skills, certifications, availability, crew membership, contractor reference, and contact details. Crew records group technicians for dispatch. Resource assignment records the target type and resource ID, then mirrors the resolved name into the work order for familiar operator review.
Resource assignment normally requires a work order that is still ready for dispatch, such as a newly created work order. If assignment fails, check the work-order status, the technician or crew record, and the operator's work-order permissions before treating it as a data problem.
Step 4: Execute Field Work
Field users can review assigned work, update progress, capture photos or voice notes, scan QR codes, and report new issues when the workflow is enabled.
Execution updates should preserve:
- start time and completion time;
- field notes;
- photos or files;
- issue count or finding category;
- parts or inventory references when available;
- blocker reason when work cannot proceed.
Step 5: Review Preventive Maintenance and Parts Signals
Preventive-maintenance templates define recurring work, and schedules carry due dates. When PM-to-work-order generation is enabled, due schedules create work orders idempotently: rerunning the job should not create duplicate work orders for the same scheduled occurrence.
Generation normally runs automatically. Operators review upcoming and overdue work in the preventive-maintenance calendar, dashboard, and CMMS overview. Overdue preventive maintenance should be handled like a planning signal: confirm the schedule, equipment, window, owner, and whether the generated work order is already in the backlog.
When spare-parts and inventory workflows are connected, review part availability before dispatch and record parts consumed during execution. Low-stock, issue, receive, and transaction history help explain why a work order is blocked or ready to proceed.
Step 6: Review Closeout
Before closing:
- Confirm field execution is complete.
- Review source status and common status.
- Check required evidence and service reports.
- Confirm root cause and action taken.
- Record follow-up recommendations.
- Synchronize closeout or feedback according to the integration mode.
Expected Output
At the end of the workflow, the work order should have:
- confirmed asset and location;
- assigned owner and execution record;
- updated lifecycle status;
- evidence files and closeout notes;
- feedback fields for maintenance analytics;
- sync state for connected CMMS or EAM providers.
Validation Checklist
- Operators can find open, assigned, blocked, completed, and closed work.
- Provider status and common status are both visible.
- Asset links open the intended equipment or location.
- Field users can upload evidence under the correct work order.
- Closed work orders preserve root cause, action, outcome, and feedback.
- Sync errors are visible to the owner.
Troubleshooting
| Symptom | Check |
|---|---|
| Operator cannot see assigned work | Role, tenant, site scope, provider filter, and status filter |
| Asset context is missing | MDM publication, alias mapping, retired asset handling, and model binding |
| Work cannot be assigned | Owner field, provider ownership rule, workflow status, and permission |
| Evidence upload fails | File size, file type, folder permission, ECM policy, and network state |
| Closeout cannot synchronize | Provider permission, field mapping, status transition rule, and sync log |
| Overdue preventive-maintenance schedule does not create work | Schedule due date, generation setting, existing generated occurrence, and schedule status |
| Parts are unavailable | Spare-part catalog, inventory transaction history, low-stock rule, and warehouse scope |