What Breaks First When You Connect a Manual Business Workflow to an API

Boštjan Korošak suggests starting with a case that went wrong rather than with a description of the normal process. Watching where the person copying the data pauses, corrects a value or asks a colleague shows the decisions hidden in data entry: recognising that "Acme" and "Acme Ltd" are the same customer, or knowing what an empty delivery date means. Before automating, the copying has to be separated from the judgement.

Using an order workflow as an example, the article then covers approvals and ownership of data. A status of "approved" does not say what was approved – price, quantity or payment terms – so approval is tied to a specific revision, with clear rules on which edits require approval again. Each shared value needs one system that owns it; once fulfilment has started, changes are handled as amendments and cancellations rather than edits to the record.

The last part deals with failures. A request that goes unanswered has an unknown outcome, so the integration needs idempotency keys or unique external references before it retries, and retries are spaced out with increasing delays. People need error messages they can act on, a history of what has already been attempted and a named owner for unresolved items. The article ends with a checklist of questions to ask before building the integration.