A request is saved, but creating its invoice in another tool fails. If the application displays a generic error, the user may submit the request again and create a duplicate.
Separate the steps
Record the internal request and the external action independently. Show whether work is saved, waiting or confirmed by the provider. Keep references that let staff trace both sides.
Decide which failures can retry automatically and which need review. Invalid information requires a different response from a temporary interruption.
Design the operator path
Give the responsible person enough context to identify the affected record and retry the specific failed step. Repeating the whole workflow may create another document or message.
Test a provider timeout, lost access and a repeated response. Inspect the destination as well as the application's message. Provider plan and API limitations need checking for the actual setup.
A custom application can make these dependencies understandable to users. Include the failure and recovery behavior in the scope rather than treating the external connection as a black box that is either on or off.
Provide an example of a saved request with a pending external action in the user guide. It gives staff a recognizable state to discuss when a real interruption occurs.