A connected workflow may succeed in one system and fail in another. If the design assumes all-or-nothing delivery, people discover incomplete work only after it causes an operational problem. A supplier update may be accepted by one system while the next system is offline. Calling the whole workflow successful at that point hides an incomplete business outcome. Decide which state remains pending, who sees it, and whether a safe retry or manual repair is required.
What good engineering looks like
What must remain true when the destination is unavailable after the source has accepted the change? Answer this for a named workflow and an accountable team. Identify the information needed at the moment of decision, the system that can settle a dispute, and the route for correcting dependent copies. The technical design should make those business rules visible to the people who operate and support the handoff.
-
Define the committed state and the point at which a message can be retried safely.
-
Show an operator the failed handoff, its owner and the next action.
-
Reconcile the final state after recovery rather than assuming a successful retry proves the business outcome.
-
A named owner for a rejected, delayed or repeated item.
-
Evidence that the receiving system applied the intended business state.
A practical starting point
-
Choose one real case and write down its trigger, expected outcome and responsible team.
-
Interrupt one dependency during a realistic transaction.
-
Confirm that the original system preserves an honest state, the operator can identify the affected record, and recovery does not create a second supplier. Repeat the test after the dependency returns, including any reconciliation needed.
-
Record what the test exposed, who will resolve each open question and how the fix will be checked.
Keep the first design small enough to review with the people who run the process. Test an exception alongside the normal case. A successful transport test shows that data moved; it does not by itself prove that the receiving team can make the right decision or recover from a partial failure.
The decision to make
Some actions need a deliberate reversal or manual decision. A retry alone cannot repair every partial failure. Decide what level of timing, traceability and recovery this workflow actually needs. Document assumptions that remain untested and revisit the choice when a partner, process or business rule changes. The point is a dependable operating decision, not simply a working interface.
Explore Algoza's related services: https://algoza.co.za/services/integration