If AFAS succeeds but a downstream system fails, preserve the successful part and recover only the failed dependency. Do not rerun the whole order chain. A partial result is not an unclear failure: it is a known state in which the financial order exists while, for example, the parcel or route still needs attention.
A chain has several established facts
Processing an online store order rarely consists of one API call. First the source order is validated, then a debtor record or sales order may be created in AFAS, and only afterwards a parcel in Sendcloud or a stop in route planning. Each step has its own external identity, response and repeatability. One red indicator for the entire chain hides which facts have already been established.
Model provider steps separately and record their dependencies. A logistics step may only begin once AFAS has accepted the order, for example. If logistics then fails, the AFAS step remains complete. The main action receives “completed with warning” or “attention needed”, not the misleading status “nothing happened”. This makes Connect more than a forwarding service: it retains the state of the process.
Use a partial-results matrix
| AFAS | Logistics | Meaning | Safe action |
|---|---|---|---|
| Not started | Not started | Validation or a filter stopped the order | Correct the source or confirm the exclusion |
| Succeeded | Not started | A dependency or configuration is blocking progress | Investigate logistics readiness only |
| Succeeded | Failed | The financial identity exists | Recover and rerun the failed substep |
| Uncertain | Not started | The outcome of the external write is unknown | First verify receipt in AFAS |
| Succeeded | Succeeded | Chain complete | Retain the audit trail |
The matrix prevents operations from using “retry” as a universal button. Give the button a precise meaning: rerun only this provider step, recalculate dependencies and skip side effects that already have a receipt.
Fictional example: an ERP order without a parcel
Fictional example: order 39014 from camping online store Buitenstroom is correctly created as a sales order in AFAS. The subsequent Sendcloud step fails because the configured sender account is temporarily unavailable. Desk shows the AFAS substep in green with its external order identity, and the parcel step in red with the specific error.
An administrator restores the Sendcloud account and selects “rerun” for the parcel step only. The dependency check confirms that AFAS is still complete. One parcel is created; the AFAS sales order is not submitted again. The final check then recalculates the main status. This fictional scenario shows how a chain remains recoverable without a technical incident creating a duplicate financial order.
Acceptance criteria for recoverable chains
- Every external write operation has its own status, attempt number and external identity.
- A downstream step visibly identifies the successful step it depends on.
- An error in a child step does not change a successful parent back to failed.
- Rerunning first checks existing receipts and the current configuration.
- The final status distinguishes full success, a warning and the need for manual attention.
- An employee can see what the customer may already expect and what is still missing.
In Desk that last explanation belongs beside the order, so customer service does not have to infer what happened from three supplier portals. For the broader architecture, the article on reliable online store–ERP integrations helps define the owner and recovery path for each step.
Also make the customer commitment depend on the correct partial result. “Your order has been processed” may be financially true while no parcel exists yet; “your order has been dispatched” is then incorrect. Define which internal and customer-facing statuses may change for each piece of external evidence. For example, let AFAS acceptance confirm only administrative processing and wait for an actual parcel identity before providing tracking. During recovery, check whether earlier notifications have already been sent so rerunning does not send the same email or webhook to a customer channel. Include both the original error and the recovery action in an incident report: which substep failed, who changed the configuration, which existing evidence was reused and which follow-up notification was deliberately not repeated. This makes partial success a manageable business status rather than a technical footnote.
Finally, give every chain an owner for the grey area. Technology can show the steps, but operations decides, for example, whether an order without a parcel still needs to be dispatched manually today. Record that decision against the order so the next shift does not start again.
Want to divide a fragile order chain into verifiable, recoverable steps? Discuss your provider workflow with Yindle.