Review waiting work before restarting a connection

What this means for your practice

Review held work before sending it again. Account for items staff completed manually during the outage and requests that changed while the connection was unavailable.

Questions to take to your supplier

Recover a test queue after one fictional item was completed manually. Can the reviewer identify and exclude it as appropriate? Record who approves the remaining replay and who owns uncertain cases. Restoring the connection is only part of restoring an orderly working process.

Agree the working process

Before releasing held work, establish what happened during the interruption. Staff may have completed some items manually, changed the underlying records or decided an action is no longer appropriate. Keep a working record of those decisions through the approved fallback process so recovery has evidence to use. Ask the supplier to show how the waiting list is compared with current records and how uncertain items are held for review. Include an outgoing message in testing if the workflow sends them, because an obsolete communication cannot be corrected simply by deleting a duplicate task later.

Name the person authorised to approve replay and the owner of unresolved exceptions. Rehearse restarting after one fictional item was handled manually and another changed while waiting. Verify the final receiving outcomes, not only that the queue emptied. A useful recovery restores an orderly process with the right work still active, rather than treating successful delivery of every old request as the definition of success.

How to check the result

Count duplicate or obsolete actions created during recovery.