CMMS–ERP integration: decide who owns each transaction

Topics: CMMS–ERP integration; EAM transaction ownership; work-order material records; maintenance purchasing interfaces.

The CMMS says a spare was issued. The ERP says it was issued twice. Both records came from the same integration, which retried after a timeout. The transport layer recovered, but the business transaction did not.

CMMS–ERP integration needs an ownership and recovery contract for each event. The contract should explain who creates the event, who authorises it, what the receiving system may change and how both sides establish the final result when a response is lost.

Map one flow all the way to its consequence

Start with one approved work-order and material flow. Name the identifiers and the system responsible for each: work order, asset, item, serial where relevant, location, cost object and transaction reference. Define which system owns each status and how its meaning maps to the other system.

This is an illustrative ownership model. The correct allocation depends on the installed systems and process. What matters is that two applications cannot silently become authoritative for the same field.

Vendor APIs expose business actions with different consequences. SAP, for example, documents separate service-entry operations for submission, withdrawal and revocation of approval. The presence of an endpoint does not grant the integration account business authority to use it. SAP service operations

Follow a lost acknowledgement

Illustrative example. A confirmed stores issue of two units against work order W-310 creates event E-901. The ERP accepts it and creates material document M-662. The response is lost before the integration service records the acknowledgement.

A blind retry could change the issue from two units to four if the receiver accepts it as a new transaction. An integration log showing “retry succeeded” would then conceal a business error.

Use the target API's documented idempotency or duplicate-control mechanism where available, and verify its actual scope. Do not assume that sending the same JSON twice is safe. Where the API lacks a suitable guarantee, design controlled deduplication, status lookup and reconciliation with the vendor or implementation owner. An ambiguous result may need a review queue rather than an automatic retry.

The event identity must survive a retry, and the same identity must never be reused for a changed payload. Record the source system, event ID, payload version, relevant business date, target reference and processing state. If two workers pick up E-901 together, the receiver or integration design must also prevent concurrent duplicate effects. A preliminary “does this exist?” lookup alone can leave a race between that check and the posting.

Amazon's Builders' Library explains this design problem using caller-provided request identifiers and atomic handling of the identifier and its effects. It is relevant implementation guidance, not a guarantee that a particular ERP endpoint provides those controls. The pilot must demonstrate what the selected endpoint actually does. Making retries safe with idempotent APIs

Check how long the receiver retains its duplicate-detection record and which caller or transaction scope the key covers. A retry after that retention window may no longer receive the original protection. Include a delayed replay in the test set; when the guarantee has expired, reconcile the business outcome before attempting another write. Creating a fresh key to escape an ambiguous result can create the duplicate the design was meant to prevent.

Separate corrections from repeats

A repeat delivery of E-901 should not create another business event. A genuine correction is different: it needs a new authorised event linked to the original transaction. Preserve who requested it and why. If financial posting has occurred, use the ERP's supported reversal or adjustment process rather than deleting integration history.

Out-of-order events need similar care. A return may arrive before the issue acknowledgement. A work-order update may reference an asset mapping not yet loaded. Queue the dependent event with a clear reason and owner; do not create a temporary material or cost object merely to satisfy the interface.

Record source event time, processing time and relevant business date separately. A late message does not automatically belong in the current accounting period. Finance owns the treatment of closed-period effects.

Compare the supported interface options

Start with a vendor-supported connector if it represents the required event and exposes enough evidence to reconcile failures. Test its retry behaviour rather than assuming the product label guarantees it. An integration platform may simplify mappings and monitoring across several systems, but the team still owns event identity, permissions and business recovery. A custom adapter can address a specific unsupported contract; it also leaves the team responsible for maintaining that contract through ERP upgrades. Compare all three using the same lost-response and duplicate-event tests.

Build the pilot around failure cases

Limit the first pilot to one transaction family, one location and a known mapping set. Use an EAM/ERP sandbox or authorised read-only extracts with a staging ledger. The integration account gets only the permissions needed for that scope; production posting and administrative privileges are excluded from this phase.

Baseline the current number of unmatched events, handling time and exception age over a stated window. Preserve the denominator for both source events and target documents. A proposed test set might include 80 ordinary events and 20 injected failure cases; those illustrative counts do not establish statistical reliability.

Test duplicate delivery, lost acknowledgement, unavailable target, unknown item, revoked credentials, out-of-order return and a correction to an already posted event. Define the expected outcome before the run. Reviewers should see the source reference, payload version, processing attempts, target document and resolution history for every case.

Acceptance includes one intended business effect per authorised event, no orphaned target postings, preserved exceptions and successful recovery without bypassing approval. Measure elapsed delay and operator effort separately. A high delivery percentage is insufficient if the undelivered remainder includes an unexplained posting.

Reconcile both directions: source events without a target result and target documents without a recognised source event. Agree which legitimate manual transactions are outside the interface population so they are not mistaken for orphans. The exception owner should be able to distinguish queued, rejected, posted, reversed and outcome-unknown events without searching application logs by hand.

Make rollback a business decision

Stop the pilot on unexpected writes, access leakage, missing source identity or a duplicate business effect. Disable the affected connector and retain the event journal. If staff use the approved manual process during the interruption, record those postings against the queued business events. Reconcile them before replay so recovery does not post the manual work again. Restart from an agreed checkpoint and check the whole affected batch, including events that appeared successful.

Once real postings exist, “rollback” rarely means restoring a middleware database. The business may require supported compensating transactions and finance approval. Demonstrate that path in the sandbox, with the original postings still traceable.

Keep the pilot boundary at the agreed business-system interfaces. Any proposed connection to operational technology requires a separate architecture and access review with the relevant owners.

Summary and next actions

The integration is dependable when the business can explain what happened despite a timeout, duplicate or late event. Field ownership and recovery rules make that explanation possible; middleware alone does not.

1. Map one work-order-to-material flow, naming the owner of each business fact.
2. Write the event contract, identifiers, approval boundary and correction path.
3. Baseline exceptions and test the normal and failure paths in the sandbox.
4. Review reconciliation evidence and recovery before authorising any later production scope.

For an integration assessment, bring the current systems, transaction family, ownership map and error categories. Synthetic event examples are sufficient to start; no live credentials or equipment connection is needed.