Maximo integrations

One interface, taken apart field by field.

Purchase orders leave IBM Maximo for Microsoft Dynamics 365 and goods receipts come back. This page walks that boundary: which system owns which field, which direction it moves, who signs for it, and what deliberately never crosses. We built it for a UK ferry operator inside a seven month move to IBM MAS 9.0.

Schematic of integration patterns connecting Maximo to ERP, GIS, SCADA and identity systems

What the boundary costs over ten years

A data contract is a standing commitment between two systems that will each change without asking the other. Programmes fund the build and inherit the run.

Four artefacts decide what the run costs: the field schedule, the direction and signature ledger, the runbook, and a named owner on each side. This page walks one boundary through all four. Where the run needs a rota rather than a rescue, it sits under MaxIron-managed hosting and support.

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

The schedule above is field detail. This is the version a change board reads, and the list underneath it is the part most often quoted back to us.

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 test environment with both owners in the room. An interface that has not passed these is not finished, whatever the build plan says.

  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, we say so before quoting.

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 say so and 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.

Bring your interface list, however out of date.

Send the diagram, the spreadsheet, or the names people use in meetings, and mark the one you would least like to lose on a Friday evening. We return a field schedule for each boundary, the transport we would keep, and what running it costs.

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