Maximo integrations

Connect IBM Maximo to the systems that run your business.

MaxIron designs, builds and supports interfaces between IBM Maximo and ERP, finance, GIS, telemetry and field systems. Each interface has agreed field ownership, direction, error handling and recovery. The purchase-order and goods-receipt example comes from our published UK ferry operator programme.

Discuss integration requirements See the MAS upgrade path
Schematic of integration patterns connecting Maximo to ERP, GIS, SCADA and identity systems

Connected systems

Each connection has a direction and a system owner

MaxIron defines the interface contract, builds the mapping and proves recovery. Counterpart teams approve their fields, endpoints and change windows before the integration baseline closes.

Conceptual maintenance assets, stores and field equipment linked through shared structured records
Conceptual illustration

Keep maintenance, purchasing and field work in step.

Connected systems should carry the right information to the people who need it. We agree record ownership, transaction rules and recovery behaviour across Maximo and its counterpart systems, so teams can trace what was exchanged and resolve exceptions without relying on undocumented workarounds.

See finance integration within a MAS upgrade

Asset and work record

IBM Maximo / MAS

Object structures, REST APIs and the Maximo Integration Framework.

MaxIron owns the agreed mapping, retry handling and interface runbook.

  • ERP and finance

    Purchase orders → · ← goods receipts and financial references

    Finance owns commercial codes and ledger rules.

  • GIS

    ← asset location and network references →

    GIS and asset owners agree identifiers and location authority.

  • SCADA and telemetry

    ← agreed readings, events and condition signals

    Operations approves thresholds and the work raised from a signal.

  • Mobile and field systems

    Work assignments → · ← completion evidence

    Field operations approves dispatch, offline and close-out rules.

Illustrative system map; arrows are relative to Maximo. The signed interface schedule sets actual direction, field authority, reconciliation and error handling.

The boundary as a controlled document

Seven fields, and the person who owns each one

IF-PO-GR-014

Every interface we build leaves with this table attached to it, versioned with the estate. Field names follow the purchase order and goods receipt boundary; the owners are the people who sign amendments to it.

Field Source Target Frequency Owner
PO_NUM IBM Maximo Dynamics 365 On approval Maximo platform lead
PO_LINE_QTY_COST IBM Maximo Dynamics 365 On approval Maximo platform lead
WO_ASSET_REF IBM Maximo Dynamics 365 On approval Reliability lead
RECEIPT_QTY_DATE Dynamics 365 IBM Maximo On receipt Finance systems lead
INVOICE_MATCH_STATE Dynamics 365 IBM Maximo Hourly Finance systems lead
VENDOR_CODE Dynamics 365 IBM Maximo Nightly, 02:10 Finance master data owner
COST_CENTRE Dynamics 365 IBM Maximo Nightly, 02:10 Finance master data owner

Direction and signature

Five movements across the line, and who signed for them

Interface owners approve direction, field authority and the boundaries of each connected system.

What moves From Direction To Signed by
Committed spend against an approved purchase order IBM Maximo → Dynamics 365 Finance systems lead
Receipt quantity and receipt date Dynamics 365 → IBM Maximo Maximo platform lead
Supplier and cost centre reference data Dynamics 365 → IBM Maximo Finance master data owner
Cancellation and closure state on a live order IBM Maximo ↔ Dynamics 365 Both leads, on one change record
Rejected messages and their reason The interface → The support rota MaxIron service manager

What deliberately never crosses

  • Work order status. Finance holds committed spend; maintenance progress stays in IBM Maximo.
  • Failure codes, meter readings and condition data, which reliability owns and nobody downstream reads.
  • Supplier bank details, which stay inside Dynamics 365 under its own approval path.
  • Any write to a posted invoice. Corrections are raised in Dynamics 365 by the finance team.

The boundary under load

A goods receipt rejected at 18:40 on a Friday

Finance made a formerly optional field mandatory in a Friday release, which is the commonest way a working interface stops working. Timings are illustrative; the order is what we build to.

  1. 18:40

    A goods receipt is rejected on the far side. SUPPLIER_SITE became mandatory in a Friday finance release.

    Written The rejection, carrying the purchase order number and the reason rather than an exception class.

  2. 18:41

    Three retries run with backoff, then the message parks on the dead letter path. Nothing is discarded.

    Written The parked message and its retry history, against interface IF-PO-GR-014.

  3. 18:45

    The alert reaches the support rota, naming the interface, the record and the reason.

    Written The alert and the rota member who acknowledged it.

  4. 19:05

    The engineer on call works the runbook entry for a rejected receipt, confirms nothing is queued behind it, and holds the mapping change for Monday.

    Written The decision to wait until Monday, and the name against it.

  5. 09:30

    The mapping change goes through normal change control, with the finance systems lead agreeing the amendment to the contract.

    Written The change record, referenced to the clause of the data contract it amends.

  6. 09:45

    Parked messages replay. Idempotent handling means the receipts that did get through are not posted a second time.

    Written The replay, and a reconciliation count of zero.

The mapping fix is an hour's work whether it is found on the Friday or nine days later. The alert route, the runbook and the named owner are what make it a twenty minute decision on the Friday.

Demonstrated, not described

Five tests the finance team watches before handover

Run in a representative test environment with both system owners witnessing the results. Signed acceptance establishes readiness for production.

  1. T1

    A replayed message cannot post twice

    Passes when
    The same goods receipt is sent twice and the received quantity in IBM Maximo moves once.
    Witnessed by
    Finance systems lead and Maximo platform lead
  2. T2

    A rejection reaches a person rather than a log file

    Passes when
    A deliberately malformed receipt parks on the dead letter path and the rota alert names the order and the reason inside five minutes.
    Witnessed by
    MaxIron service manager and your on-call rota
  3. T3

    A code that exists on one side only fails loudly

    Passes when
    The message is rejected with the unmatched cost centre quoted, and no partial record is written to IBM Maximo.
    Witnessed by
    Finance master data owner
  4. T4

    The nightly reference data run lands before anyone plans against it

    Passes when
    Supplier and cost centre changes made in Dynamics 365 on Tuesday are queryable in IBM Maximo by 03:00 on Wednesday, ahead of the 07:00 planning session.
    Witnessed by
    Planning lead and finance master data owner
  5. T5

    The far side can ship a release without breaking the boundary

    Passes when
    The Dynamics 365 release reaches a test environment first, and the interface owner sits on the change board that approved it.
    Witnessed by
    Both change managers

Conditions

Three conditions we set before quoting

Each of the three sets scope, so each is settled before a price rather than in month two.

The counterpart team signs its own half of the contract

Half of this boundary lives in a system with its own roadmap. We write the data contract, put it to both sides and hold both change boards to it. Where the finance or ERP owner has not agreed their half, quoting waits.

Reference data alignment is taken first, in the open

Where asset identifiers, cost centres or supplier codes disagree between two systems, an interface carries that disagreement faster and more often. The alignment belongs ahead of the build under data migration, not buried in mapping logic.

The interval matches the decision the data feeds

Boundaries are often specified as real time when the upstream system publishes on a nightly job, or when the decision they feed is taken weekly. We propose the cadence that decision needs, and price near real time where it changes an outcome.

Beyond this one boundary

What we connect, and what we build it on

Boundaries we have built in production

ERP and finance
SAP, Oracle EBS, Microsoft Dynamics 365
ITSM, HR and identity
ServiceNow, BMC Helix, Workday, Microsoft Entra ID, Okta, SCIM
Spatial and operational
Esri ArcGIS, SCADA, historians and the IoT sources IBM Maximo Monitor reads
Documents and field
SharePoint, OpenText, permit systems and IBM Maximo Mobile clients

Transports, and what each is for

Integration Framework
Object structures, publish channels, enterprise and invocation channels. Structured Maximo-owned data on an event or a schedule.
Maximo REST API
Request and response, where a caller needs an answer now and volume is modest.
Kafka or JMS
Decoupled sides, replay, or a second consumer for the same event.
Your existing ESB
Where the estate already runs an integration platform with an operations team, new boundaries belong there.
Release path
Mappings and object structures promoted with the rest of the configuration through MaxIron Pipelines.

Point-to-point code is used only where cost, latency and ownership clearly favour it. Every boundary is assessed as scope in a Maximo to MAS upgrade and re-tested in a representative environment before cutover.

Maximo integrations, frequently asked questions

Which systems can MaxIron integrate with IBM Maximo?
In production: SAP, Oracle EBS, Microsoft Dynamics 365, ServiceNow, BMC Helix, Workday, Esri ArcGIS, SCADA and historian platforms, finance ledgers, Microsoft Entra ID and Okta, SharePoint and OpenText, and bespoke line-of-business systems.
Which integration technologies do you use?
The IBM Maximo Integration Framework, Maximo REST APIs, message buses including Kafka and JMS, and the ESB already running in the estate. Data ownership, volume, latency and recovery decide which, at design time rather than during an incident.
Who owns the interface after go-live?
A named person on each side, agreed before the build starts. Where that person is MaxIron, the boundary runs under our support contract with alert routing, a runbook and a seat on the change board. Where it is your team, they receive the same four artefacts and we watch the first weeks together.
How do you establish what is already connected?
We inventory every object structure, publish channel, enterprise service, invocation channel, REST consumer, scheduled database job and file drop we can find, then test which still move data. Estates routinely run interfaces nobody mentioned, and a few that stopped years ago.
Can you take over interfaces a previous partner built?
Yes, and it is a common way we are brought in. Each one is audited against a written schedule and ledger like the ones above. Where the design holds we keep it and document it; where it cannot be operated safely we price a measured rebuild.
Do integrations affect a Maximo to MAS upgrade?
They are usually the largest single risk in one. Every boundary is assessed as upgrade scope, changed where MAS requires it, and re-tested in a representative environment before cutover. See Maximo to MAS upgrade.

Discuss your interface scope.

Bring the connected-system list, counterpart owners and one representative message. We will identify field authority, test access and the recovery controls needed for delivery.

Bring this to the first call

  • Whatever passes for an integration diagram today, however stale
  • The interface people are nervous about, and what makes them nervous
  • Which system owns which data, wherever that is already settled
  • Named on-call contacts on both sides of each boundary
  • Any MAS upgrade, ERP change or platform move already in the plan
Discuss integration requirements Read the ferry integration case