DATIMORE · WEB-090

Keep the next handoff dependable

A printable checklist for one live business workflow, followed by a synthetic recovery exercise. All example records, roles and timings are invented. This file runs no workflow and sends no alerts.

Read the article · العربية

1. Agree the routine for your workflow

Download this page and print it, or copy the prompts into your own working document. Record references, never passwords or customer details. These blanks are for your team to complete.

  1. Expected result and deadline. Name the workflow, the requests it covers, the output, its destination and when it must be available. Include the time zone.
  2. Responsible owner and backup. Name who checks, who receives alerts, who may repair access and who confirms the business result. Agree a follow-up route when the owner is unavailable.
  3. Last verified result. Record the last correct result or task number, time and assigned person. Add the corresponding attempt number from the system records. Check where the result should appear, not only the attempt status.
  4. Failed or missing work. Choose when to compare expected requests with actual outputs. Record errors, overdue outputs and the time the monitoring check itself last ran. If checks are stale, status is unknown.
  5. Connection and input changes. Record the authorized access owner, renewal checks and recent field or rule changes. Reconfirm the intended result after a change. Never record secrets here.
  6. Safe repeat condition. Pause automatic and manual repeats. Check current approval, unchanged details and whether the output exists. Confirm that no earlier attempt can still finish later and nobody else is repeating the work. Name who authorizes one controlled attempt. If any of this is uncertain, stop for review.
  7. Recovery and follow-up. Confirm exactly one correct output with the intended recipient. Record the evidence, who checked it and when. Note the cause, prevention task and next check.

2. Rehearse one missing purchasing task

Exercise date: 3 October 2026. All times use Coordinated Universal Time (UTC). The invented rule is one internal purchasing task per approved request, within 15 minutes. Creating an order, sending a supplier message and releasing payment are outside this example.

Starting records: request R101, approved at 08:40, produced task T101 at 08:55. Request R102 is approved at 09:00 with cost centre OPS and assignee Purchasing coordinator. Its task is due by 09:15. The connection loses access at 09:01.

  1. Detect · 09:15

    The attempt at 09:02 failed before creating a task. The simulated check compares approved requests with the task list and finds R102 missing. Its alert record is addressed to the Operations lead and acknowledged at 09:16; the Operations deputy is the backup. These are exercise records, not delivered messages.

  2. Protect · 09:16

    The lead checks the last verified output, T101, and the failed run. They pause repeat attempts for R102 and assign the access repair to the authorized System owner. The 09:15 deadline remains recorded as missed.

  3. Repair and check · 09:25

    The System owner restores access. The lead confirms R102 is still approved, its cost centre and assignee have not changed, and the destination contains no R102 task. Earlier attempts can no longer finish; only the lead can repeat the failed step in this exercise.

  4. Recover · 09:26

    One controlled attempt creates T102 for R102, cost centre OPS, assigned to the Purchasing coordinator. In a separate duplicate-prevention test, a second attempt with the same request number shows the existing task number and creates nothing. This safeguard is an assumption of the simulation, not a feature of every tool.

  5. Confirm · 09:27

    The coordinator confirms one correct, visible T102. The lead records the task reference, checker and time before closing the incident. The next scheduled check at 09:30 finds both expected tasks once. Add a connection-access review to the upkeep list.

Checked result: two approved requests, two distinct tasks, no duplicate for R102. The missed deadline is retained. Recovery does not erase the interruption.

When to stop and review

The reply is lost after a task is created

If the destination shows exactly one correct T102, record that result without creating another. If it cannot be checked or the result is wrong, keep the incident open. A missing reply is not proof that nothing happened.

The request changes or required information is missing

Hold the attempt for the responsible person to correct or reapprove the request. Do not reuse an earlier approval for changed work.

No run or monitoring check appears

Compare expected requests with outputs even when no error was reported. If the monitoring check itself is missing or stale, ask the backup to check manually; do not report everything as healthy.

This written example uses invented records to explain one recovery routine. It does not test connections to working systems, real alerts or access permissions. It also does not test records appearing late or two attempts happening at the same time. Ask the system owner to test those cases in a separate setup approved for testing before relying on the workflow. If you cannot tell whether work already happened or whether repeating it can create another task, stop for review.