Skip to main content

Work-Order Lifecycle and Status Mapping

Every CMMS provider uses its own status values and transition rules. FactVerse CMMS Operations uses a common lifecycle so operators can review work orders across providers, sites, and service lines without losing the original provider status.

Use this guide before enabling dashboards, AI Agent summaries, dispatch workflows, or write-back.

Mapping Flow

Prerequisites

RequirementWhy it matters
Provider status listEach source system must provide all active, closed, canceled, and exception states
Transition meaningThe team must know the operating meaning behind each provider status label
Sample recordsReal examples are needed for edge cases such as blocked, canceled, reopened, and partially completed work
SLA rulesResponse target and completion target often depend on priority, category, site, and provider
Field ownershipThe customer must decide which system owns status updates
Review ownerA maintenance or operations owner must approve the mapping before rollout

Source Data Inputs

InputUse
Source status code and labelPreserves provider vocabulary and audit trace
Source priority and severitySupports normalized priority and SLA review
Status transition historyShows how each work order moved through provider workflow
Assignment and owner fieldsSeparates provider ownership from local execution responsibility
Due dates and SLA fieldsSupports overdue, breach, and response-time reporting
Closeout fieldsCaptures resolution, root cause, action taken, and verification
Exception fieldsRecords hold reason, cancellation reason, reopen reason, or sync error

Common Lifecycle

Common statusMeaningTypical source examples
RequestedA request, issue, alert, or recommendation needs reviewNew, Submitted, Created, Open
TriagedThe team has reviewed scope, asset, priority, and duplicate riskReviewed, Accepted, Validated
ApprovedThe work should proceed under the site processApproved, Authorized, Released
AssignedA team, technician, contractor, or provider owns the next actionAssigned, Dispatched, Scheduled
In progressExecution has startedStarted, On Site, Work In Progress
BlockedExecution is waiting for access, part, approval, safety, or provider actionOn Hold, Waiting Parts, Pending Approval
CompletedField execution is complete and closeout needs reviewResolved, Work Complete, Completed
ClosedCloseout, evidence, and synchronization state have been recordedClosed, Verified, Archived
CanceledThe work is stopped by a source decision or duplicate resolutionCanceled, Rejected, Void
ReopenedA completed or closed item needs follow-up workReopened, Returned, Follow-up Required

Priority Mapping

Normalize priority without hiding the source value:

Common priorityTypical meaning
CriticalSafety, production continuity, compliance, or major service impact
HighUrgent operational risk or near-term SLA impact
MediumPlanned maintenance or moderate operational impact
LowRoutine work, minor issue, or backlog item
InformationalRecord, observation, or advisory with no immediate dispatch need

Keep source_priority visible in operator views and exported evidence so provider teams can communicate using their native vocabulary.

SLA Mapping

FieldPurpose
response_due_atTarget time for review, acknowledgement, or dispatch
completion_due_atTarget time for completing the work
breach_stateOn track, at risk, breached, waived, or excluded
sla_sourceProvider rule, contract rule, site rule, or manual override
sla_exception_reasonAccess restriction, waiting part, safety hold, customer hold, or provider exception

SLA logic should be validated with the customer using real work orders from several sites and providers.

Configure the Mapping

  1. Export recent and historical work orders from each provider.
  2. List all status values, priorities, hold reasons, cancellation reasons, and closeout codes.
  3. Group provider statuses by operational meaning.
  4. Map each value to a common lifecycle state.
  5. Identify statuses that need operator review because the meaning changes by service line.
  6. Map priority and SLA fields separately from status.
  7. Validate the mapping with open, blocked, completed, closed, canceled, and reopened examples.
  8. Publish the mapping with an owner, effective date, and review cadence.

Synchronization Rules

RuleRecommended behavior
Unknown statusKeep the source value visible and route the record to review
Provider status changes after importUpdate common status and keep transition history
FactVerse handoff creates a provider recordStore both the FactVerse draft ID and provider work-order ID
Write-back failsKeep the attempted update in sync history with retry and owner visibility
Closed work order reopensPreserve the closed record and show the reopened lifecycle state
Duplicate resolutionKeep duplicate links and cancellation reason visible

Expected Output

The mapping package should include:

  • provider status table;
  • common lifecycle mapping;
  • priority mapping;
  • SLA mapping;
  • exception and hold reason mapping;
  • sample records used for validation;
  • owner and review cadence;
  • sync behavior for read-only, handoff, and write-back modes.

Validation Checklist

  • Every active provider status has a common lifecycle mapping.
  • Source status remains visible in unified views.
  • Canceled, blocked, reopened, and duplicate states are tested.
  • SLA breach calculations match customer expectations.
  • Write-back transitions are approved by the customer before use.
  • Unknown status values route to a visible review process.

Troubleshooting

SymptomCheck
Too many work orders show as RequestedProvider triage and assignment statuses may be unmapped
Completed work appears openCompletion and closeout states may be separated in the provider system
Reopened work loses historyTransition history and prior closeout fields may not be imported
SLA reports disagree with providerTimezone, pause rules, exception reasons, and source SLA fields
AI Agent summaries conflict with dashboardDataset freshness, status mapping version, and source status visibility