Many building, campus, and facility portfolios already use several CMMS or EAM providers. Different buildings, systems, contractors, and service lines may keep their own work-order platforms. FactVerse can provide a common operations layer across those providers, while each downstream CMMS continues to own the records and execution processes that the customer needs to keep.
Use this guide when a customer wants a centralized maintenance operations view across multiple CMMS providers, especially when the downstream systems mainly handle work-order management.
Target Architecture
The design has four practical goals:
- Give operators one place to see work-order status across buildings, systems, and service providers.
- Keep source-system ownership clear so teams know where execution decisions are made.
- Normalize asset, location, status, priority, SLA, attachment, and closeout data for reporting and AI workflows.
- Support controlled handoff or write-back after the customer approves the integration model.
Prerequisites
| Requirement | Why it matters |
|---|
| Provider inventory | The program needs a list of CMMS, EAM, contractor, and building systems by site or service line |
| Source ownership | Each downstream system needs a named owner for access, field meaning, status mapping, and exception review |
| Asset identity baseline | Work orders need to map to stable buildings, systems, spaces, equipment, and MDM identities |
| Status and SLA taxonomy | Provider states, priorities, and SLA rules need a shared interpretation for unified operations |
| Integration access | APIs, exports, middleware, service accounts, network paths, and rate limits need to be confirmed |
| Write-back decision | The customer needs to decide which providers are read-only, handoff-based, synchronized, or provider-owned |
| Security and audit model | Service identities, scopes, evidence retention, and sync logs need customer approval before rollout |
Operating Model
| Layer | Responsibility |
|---|
| Downstream CMMS and EAM | Maintain native work-order records, provider-specific workflows, technician dispatch, and local execution rules |
| DFS | Connect to provider APIs, scheduled exports, files, or middleware; validate and normalize records |
| MDM | Align provider asset IDs, building systems, locations, equipment names, and duplicate references |
| FactVerse CMMS Operations | Provide the common work-order view, status mapping, assignment context, SLA review, and cross-provider history |
| Facility Operations | Add site, space, equipment, inspection, and operations context around each work item |
| Predictive Maintenance | Generate condition-based maintenance recommendations that can be reviewed before work-order handoff |
| ECM | Manage attachments, service reports, SOPs, photos, and closeout evidence across providers |
| FactVerse AI Agent | Summarize, compare, draft, and explain maintenance context under explicit permissions and review gates |
| Input | Use |
|---|
| Provider work-order exports or APIs | Bring work-order ID, status, priority, owner, timestamps, service type, and closeout fields into the common model |
| Asset and location references | Align provider records with buildings, systems, spaces, equipment, and MDM identities |
| Provider status taxonomy | Maps native provider states to the shared lifecycle used by operators |
| Attachment metadata and files | Connect service reports, photos, permits, checklists, and closeout evidence to unified records |
| User and provider ownership data | Separates source-system ownership, execution ownership, and customer review responsibility |
| SLA and priority rules | Supports portfolio-wide backlog, response-time, and exception review |
| Sync history | Shows import time, freshness, retry state, write-back result, and exception detail |
| Handoff or write-back policy | Defines which fields can be created or updated from FactVerse and which remain provider-owned |
Integration Patterns
| Pattern | When to use it | Notes |
|---|
| Read-only aggregation | The customer needs a common view without changing provider workflows | Lowest operational risk and a good first rollout pattern |
| Controlled handoff | FactVerse creates a reviewed request or draft for a downstream provider | Useful when inspections, alarms, or predictive-maintenance findings need dispatch |
| Two-way status synchronization | Operators need current provider status and selected status updates from FactVerse | Requires clear conflict rules, retry handling, and synchronization logs |
| Attachment and evidence synchronization | Photos, reports, checklists, and closeout files need to follow the work order | Requires retention, file-size, access, and audit policy alignment |
| Provider-specific write-back | FactVerse updates assigned fields in a provider CMMS | Use only after field ownership, permissions, and rollback behavior are agreed |
Common Work-Order Model
| Field | Purpose |
|---|
provider_id | Identifies the source CMMS, EAM, contractor system, or managed service provider |
source_work_order_id | Preserves the native work-order identifier from the downstream system |
common_work_order_id | Provides a stable FactVerse reference for unified views, dashboards, and AI workflows |
asset_ref | Links the work order to the MDM asset, equipment, system, or location identity |
source_status | Keeps the original provider status visible for audit and provider communication |
common_status | Maps provider states to the shared lifecycle used by operators |
priority and sla | Supports cross-provider urgency and service-level review |
requested_at, assigned_at, started_at, completed_at, closed_at | Enables lifecycle, backlog, and response-time analysis |
owner and assignee | Separates provider ownership from local execution responsibility |
attachments | Links reports, photos, SOP references, permits, and closeout evidence |
sync_state | Shows freshness, last synchronization result, and exception status |
Status Mapping
| Common status | Example provider states | Review point |
|---|
| Requested | New, Open, Submitted, Created | Confirm source, asset, duplicate risk, and service category |
| Triaged | Reviewed, Validated, Accepted | Confirm priority, SLA, and ownership |
| Assigned | Dispatched, Assigned, Scheduled | Confirm provider, crew, technician, and planned window |
| In progress | Started, On Site, Work In Progress | Track field execution and evidence |
| Blocked | On Hold, Waiting Parts, Pending Approval | Capture blocker reason and expected next action |
| Completed | Resolved, Work Complete, Ready to Close | Review outcome, evidence, and follow-up actions |
| Closed | Closed, Archived, Verified | Lock closeout record and preserve audit trace |
| Canceled | Rejected, Void, Canceled | Keep cancellation reason and source decision visible |
Source Ownership Rules
Use explicit ownership rules before enabling synchronization:
- Define which system can create a work order for each building, service line, and provider.
- Define which fields FactVerse can update and which fields remain provider-owned.
- Preserve the native provider ID and source status in every unified view.
- Keep a synchronization log for imports, handoff, write-back, attachment sync, retries, and failures.
- Show stale data and sync exceptions in the operator view rather than hiding them in background jobs.
- Prevent duplicate work orders when inspections, alarms, AI recommendations, and provider imports describe the same issue.
Discovery Checklist
| Topic | Questions to answer |
|---|
| Provider landscape | Which CMMS, EAM, contractor, or building systems are in scope for each site |
| Integration access | Which providers offer REST APIs, webhooks, database views, exports, SFTP, or middleware |
| Authentication | Which service accounts, API keys, OAuth flows, IP restrictions, and approval processes are required |
| Work-order fields | Which fields are required, optional, read-only, provider-specific, or customer-specific |
| Status taxonomy | How provider statuses map to the common lifecycle and where exceptions occur |
| Asset identity | How provider asset IDs map to building, floor, room, equipment, system, and MDM identities |
| Attachments | Which photos, reports, checklists, permits, and closeout documents need to synchronize |
| Write-back policy | Which fields can be written back, who approves writes, and how failures are retried |
| Data freshness | Whether the customer needs near-real-time sync, scheduled sync, or manual refresh |
| Audit and retention | How long records and attachments are retained and who can access them |
Rollout Sequence
- Inventory provider systems, work-order fields, status values, asset references, and integration access.
- Build the common work-order model and status mapping with real examples from each provider.
- Connect the first provider in read-only mode and validate unified views with operators.
- Add MDM matching for assets, locations, equipment, and service categories.
- Add attachment and evidence workflows after access and retention policy are confirmed.
- Enable controlled handoff or write-back for one provider and one service line before expanding.
- Add AI Agent summaries and recommendations after the data model and permissions are stable.
- Review exception handling, duplicate detection, and sync logs during pilot operations.
Governance
Multi-provider CMMS programs affect operational ownership. Treat the integration as an operating model with connector, data, permission, and exception-management workstreams.
- Give each provider a clear ownership boundary.
- Separate read permissions from draft, handoff, write-back, and closeout permissions.
- Use service accounts with scoped access and rotation policy.
- Review synchronization failures and stale records as operational exceptions.
- Store customer-specific provider mappings, API credentials, and field rules in the approved project repository and secret-management process.