A switch for every fragile integration
The ERP is changing and the onboarding flow writes into it. Does everything stop until it is ready?
Every system in production has integrations that sooner or later let you down: an ERP in transition, a vendor changing its API, a certificate expiring on a public holiday. If the flow using them is written as though they were always available, the first external problem becomes an internal outage.
The concrete case: the doctors' onboarding flow in a healthcare network verified documents, archived them and then wrote to an ERP through an application with dependencies locked for two years. The ERP was about to change. The writes had to be switchable off without stopping verification and archiving.
The decision
The map first: every integration toward the ERP inside that flow, written down one by one, before touching the code. Then an explicit switch, a configuration variable, behind which all the writes sit. With the switch off, document verification and archiving continue as always; the steps that wrote to the ERP are skipped; and an email goes out to configurable addresses with everything needed to complete the case by hand.
One detail the map surfaced: a code the ERP used to generate and that the rest of the flow took for granted. With writes off, that code has to be supplied by hand together with the data. Without the map it would have been discovered in production.
What holds in general
A fragile integration must be able to degrade legibly: the flow completes what it can, skips what depends on the absent system, and alerts a person with the context to close the case. The switch is a configuration variable: it goes off and on without touching the code. And the degraded behaviour must be written and tested before it is needed, because on the day it is needed there is no time to design it.
Describe the system. We'll tell you what we see.
Ten minutes, one question at a time. At the end, our honest read of the case. It's the filter, before the call.