Provider-Specific CMMS Integration Guides
Provider-specific CMMS and EAM guides should be created after the project confirms the source system, access method, required fields, and customer-approved operating model. Use this page with CMMS Work-Order Adapters to turn adapter profiles into customer-specific implementation guides.
Provider Guide Structure
Each provider-specific guide should follow the same structure:
Prerequisites
| Requirement | Why it matters |
|---|---|
| Confirmed provider | The guide should name a real provider and version or customer integration profile |
| Customer access model | REST, database view, export, middleware, or file drop changes the implementation path |
| Field dictionary | Required fields, optional fields, enums, and custom fields need customer confirmation |
| Ownership model | Read-only, handoff, synchronization, and write-back modes need separate rules |
| Test records | Real open, blocked, completed, canceled, and reopened records are needed for validation |
| Security approval | Provider credentials and network paths need customer approval |
Source Data Inputs
| Input | Use |
|---|---|
| Provider API or export schema | Defines fields and data types |
| Work-order sample set | Validates lifecycle, priority, and closeout mapping |
| Asset and location sample set | Validates MDM alignment |
| Attachment sample set | Validates ECM import and access behavior |
| Status transition examples | Confirms provider workflow meaning |
| Permission matrix | Confirms read, draft, write-back, and attachment access |
| Error examples | Supports troubleshooting and retry behavior |
Provider Profiles
| Profile | When to use it | Notes | | --- | --- | | IBM Maximo Integration | Customer uses Maximo work orders, assets, failure codes, sites, locations, and service records | Confirm Maximo status vocabulary, object-structure customization, site or org defaults, and API key access | | SAP Plant Maintenance Integration | Customer uses SAP PM orders, functional locations, equipment, plants, notifications, and closeout data | Confirm SAP OData service root, auth mode, CSRF write behavior, plant, order type, and status codes | | Generic REST CMMS Integration | Customer, contractor, middleware, or provider exposes a project-specific REST API | Confirm base URL, auth mode, push path, pull path, field map, result shape, and external ID field | | Honeywell Forge or IBMS Profile | Customer-approved Forge engagement exposes work-order, asset, alarm, or status paths through an overlay | Confirm endpoint shape, OAuth2 or API key auth, payload contract, direction of flow, and customer approval | | Infor EAM Integration | Customer uses Infor EAM work orders, assets, status values, and maintenance records | Requires provider schema and access details before implementation | | Contractor Work-Order System Integration | Service providers maintain their own dispatch or ticketing system | Usually implemented through Generic REST, webhook, scheduled export, or middleware | | Scheduled Export Integration | Customer provides CSV, SFTP, database view, or data-lake extracts | Use when API access is unavailable or read-only reporting is enough |
Baseline Field Mappings
Use these mappings as starting points for discovery. Confirm the final field dictionary, custom fields, and enum values with each customer environment.
| Provider type | Native work-order ID | Asset or equipment field | Status field | Description field | Other useful fields |
|---|---|---|---|---|---|
| SAP Plant Maintenance | ORDER_NR | EQUNR | STATTEXT | LTXT | QMEL.LTXT, PRIOKX |
| IBM Maximo | WONUM | ASSETNUM | STATUS | DESCRIPTION | FAILURECODE, WOPRIORITY |
| Infor EAM | WORKORDERID | EQUIPMENTID | STATUS | DESCRIPTION | Customer-specific priority and closeout fields |
| Custom REST API | id | equipment_id | status | description | Project-specific fields approved during integration |
Adapter-Specific Planning Notes
IBM Maximo
Plan for Maximo as a provider-owned work-order system. Confirm the Maximo root URL, service account, API key header, default site or organization, asset number mapping, location mapping, status vocabulary, priority vocabulary, and changed-date pull window.
Validation examples should include at least one open work order, one completed work order, one canceled work order, one status update, and one record with a customized status or optional field.
SAP Plant Maintenance
Plan for SAP PM as a maintenance-order integration. Confirm the OData service root, authentication mode, plant, order type, equipment or functional-location mapping, required order fields, and CSRF token handling for write requests.
Validation examples should include created, released, confirmed, technically completed, closed, and canceled orders where the customer uses those states.
Generic REST
Plan for Generic REST when the source exposes a stable API but does not match a packaged provider profile. Confirm the endpoint contract in writing before rollout. The guide should include push and pull paths, auth mode, JSON field map, result array path, external ID field, timestamp field, and error response examples.
Honeywell Forge or IBMS Profile
Plan Forge integrations as customer-approved overlay profiles. Do not assume a universal Forge endpoint set. The guide should state the approved base URL, credential mode, asset ownership, work-order ownership, alarm direction, status direction, and any fields that may be written back.
For predictive-maintenance workflows, include the fields needed to connect an advisory with the provider work order: equipment identity, status, priority, diagnosis or failure code, closeout note, root cause, and completion timestamp.
Provider Guide Procedure
For each provider, write:
- Scope and supported integration mode.
- Required source access.
- Required work-order fields.
- Asset and location mapping.
- Status, priority, SLA, and closeout mapping.
- Attachment handling.
- Authentication and service-account requirements.
- Import and synchronization cadence.
- Write-back or handoff behavior when approved.
- Validation checklist and sample test cases.
- Troubleshooting table.
Expected Output
A provider-specific guide should produce:
- provider scope and supported operating mode;
- field mapping table;
- status and priority mapping table;
- asset identity mapping plan;
- attachment and ECM plan;
- permission and service-account plan;
- test cases and acceptance criteria.
Validation Checklist
- The guide is based on a confirmed customer or provider schema.
- Required fields are validated with real sample records.
- Custom fields and enum values are documented.
- Provider ownership rules are clear.
- Write-back behavior has explicit customer approval.
- Troubleshooting examples match observed provider responses.
Troubleshooting
| Symptom | Check |
|---|---|
| Provider guide does not match customer system | Provider version, custom fields, middleware layer, and export schema |
| Required field is absent | Customer field dictionary, optional source module, and alternate mapping rule |
| Status meaning differs by service line | Service category, site-specific workflow, and provider configuration |
| Write-back behavior is unclear | Ownership model, provider permission, and customer approval record |