Did you send it, or did we drop it?
Every integration eventually produces this conversation between two teams, and it is unresolvable unless one side kept a record. The useful version keeps enough that the answer is a query rather than a claim.
What it is, and what it is not
A queryable record of every connector run: what was sent, when, in response to what, what came back, how long it took, and what happened next.
It is not application logging. Logs are written for operators, rotated when they get large, and searched by somebody with production access. This is a product surface an engineering manager can open when a supplier says they never received a change notice.
It is also not a monitoring dashboard. A green light saying the integration is healthy answers a question nobody is asking. The question is always about one specific object on one specific day.
What a run record holds
Enough to settle the argument without anybody having to be believed.
- The trigger — which change released, or which schedule fired, and who or what caused it.
- The payload sent, at the revision it was resolved at, so what crossed can be compared against what the ERP now holds.
- The response, including the status code and any error body, because a rejection with a message from the target system is the single most useful artefact in a failed integration.
- Timing — queued, started, completed — which is how a slow ERP is distinguished from a stuck connector.
- The outcome and what followed: committed, retried, suspended, or a reconciliation task raised, with a link to it.
The failure it prevents
A supplier says they never received a change notice. Engineering says it was released three weeks ago. Both are being honest and neither can prove anything.
The investigation goes to whoever has production access, who greps a log, finds a line at the right timestamp, and reports that something was sent. That does not settle it — sent is not received, and a 200 response from a middleware layer is not evidence the ERP acted on it.
Two hours later somebody discovers the target rejected the payload with a validation error that the connector treated as a transient failure and retried three times before giving up quietly. Nobody was told, because the subscription was not suspended and no task was raised. The failure was not the rejection — it was the silence afterwards.
How it meets the rest of the product
Every run is also an attributed audit row naming the connector, the run and the direction, so a value's history and the sync that produced it are the same record rather than two systems to reconcile.
Retries are bounded and idempotent, and the history shows each attempt rather than collapsing them into a final state. A run that succeeded on the third attempt looks different from one that succeeded immediately, and that difference is usually the first sign a target system is degrading.
Persistent failure suspends the connector and notifies rather than retrying forever. A subscription quietly retrying for three weeks is how an integration stops working without anybody noticing, and the notification is the difference between a bad afternoon and a bad quarter.
Reconciliation tasks link back to the run that produced them, so the question of why a difference appeared has a starting point rather than requiring an investigation.
Sync history is also where a connector's own health becomes legible before it becomes a problem. Rising retry counts, response times drifting upward, a target that begins rejecting one object type — none of those are outages, and all of them are visible here weeks before somebody files a ticket about an integration that has stopped working.
How it meets your ERP
What Manufacturing PLM can show is one side: what it sent, when, and what the target returned. That is the half most arguments turn on, and it is the half that is usually missing.
What it cannot show is what happened inside your ERP afterwards — whether a workflow there rejected the record, whether somebody edited it an hour later, whether the middleware acknowledged before delivering. Reconstructing that means using your ERP's own facilities, and the run record gives you the timestamp and payload to search against.
Because publication is all-or-nothing per release, a run either landed completely or not at all, which removes the worst class of investigation: working out which half of a structure crossed. There is no partial state to reconstruct.
The same record answers the question in the other direction during a reconciliation. When your ERP holds a value Manufacturing PLM did not expect, the run history says whether Manufacturing PLM ever wrote that field, when, and with what — which usually settles whether the difference came from a sync or from somebody editing downstream.
Where the boundary is
Retention is finite. Run history is kept long enough to cover an investigation and a holiday, not indefinitely — the permanent record of what changed and when is the audit trail, retained for the life of the tenant.
Payloads are stored with the same field-level access control as the objects they contain, so a run record does not become a way to read a cost somebody may not see. That occasionally means a run record is less complete for one reader than another, which is the correct behaviour and worth knowing before somebody reports it as a bug.
Facts
| Per run | Trigger · payload at revision · response · timing · outcome |
| Retries | Each attempt shown, not collapsed into a final state |
| Persistent failure | Suspends and notifies — never retries forever |
| Reconciliation tasks | Link back to the run that produced them |
| Audit | Every run is an attributed row alongside human actions |
| Partial state | Cannot occur — publication is all-or-nothing |
| Payload access | Field-level rules apply to run records too |
| Retention | Finite — the permanent record is the audit trail |
Frequently asked
How is this different from logs?
Logs are written for operators, rotated when large, and searched by somebody with production access. This is a product surface an engineering manager opens when a supplier says they never received a change notice — which is when the question is actually asked.
Can we see what was actually sent?
Yes, the payload at the revision it was resolved at, alongside the response including any error body. A rejection carrying a message from the target system is the single most useful artefact in a failed integration, and it is usually the thing nobody kept.
What happens after repeated failures?
The connector is suspended and you are notified rather than retrying forever. A subscription quietly retrying for three weeks is how an integration stops working without anybody noticing, and that notification is the difference between a bad afternoon and a bad quarter.
Does it show individual retry attempts?
Yes, rather than collapsing them into a final state. A run that succeeded on the third attempt looks different from one that succeeded immediately, and that difference is frequently the first observable sign that a target system is starting to degrade.
Can it tell us what our ERP did with the payload?
No, only what it returned. Whether a workflow there rejected the record later, or somebody edited it an hour afterwards, is your ERP's own audit facility to answer — and the run record gives you the exact timestamp and payload to search against.
Could half a structure have crossed?
No. Publication is all-or-nothing per release, so a run either landed completely or not at all. That removes the worst class of investigation entirely — working out which half of a structure made it across and what the receiving system did with the fragment.
How long is history kept?
Long enough to cover an investigation and a holiday, not indefinitely. The permanent record of what changed and when is the audit trail, which is retained for the life of the tenant — run history is an operational surface rather than an archive.