Account for each outage event with a verified result, a documented stop, or an open exception with a named owner.
Inquiries keep arriving, but the app you use to hand over work is unavailable. One teammate handles something manually, another waits, and a third attempt leaves you unsure whether a job was created at all. When service returns, you need to establish what is already done and what still needs attention.
Keep one temporary manual register for the outage. For each source event, separate what was supposed to happen, what someone actually did, and what you verified in the destination. Leave uncertain results open. This guide takes you from setting up the register to checking it before resuming automation. It does not restore the service itself.
Use the blank CSV register and five completed fictional cases. These are a proposed procedure and synthetic data, not results from testing in your accounts.
1. Choose one register, an owner, and the outage start time
Use an existing restricted work list that the owner and backup can access during the outage. If that is unavailable too, choose one available, approved location for the temporary list. Avoid separate copies for each teammate. If you have no safe place to keep the register or cannot access the original source, leave affected cases unresolved; this procedure does not restore data access.
Record these incident details above the event list:
- Incident ID and the start of the affected period, including the time zone.
- Incoming request source, unavailable destination, and affected automation.
- Register owner, backup, and next joint review time.
- Who may make manual changes and who will check pending automated attempts.
The maintainer needs to establish whether any runs are still retrying or waiting for service to return. An agreement between teammates does not stop automated attempts. Until their status is known, do not create anything again for a case with an uncertain result.
Keep only necessary identifiers, states, and references in the temporary list. Leave detailed material in its original restricted source. Both the owner and backup need actual access to that material; a link in a spreadsheet is insufficient.
2. Record the event before handling it manually
One row represents one source event. Retain its original ID and the request ID. Multiple events can belong to the same request, such as receipt followed by cancellation. Review them together while retaining what changed in each event. Do not merge two separate inquiries from the same client by email address.
If the source has no stable ID, assign a temporary identifier and link to the traceable original. That identifier alone does not prove a destination match; someone will need to assess it. Preserve the original receipt time. Record the time of manual handling in a separate field.
The template uses the fields below. CSV keys remain stable for any later comparison.
| CSV field | What to record |
|---|---|
incident_id |
Shared outage ID. |
source_event_id |
ID of this particular source event. |
request_id |
ID of the request the event belongs to. |
source_reference |
Traceable original in the restricted source. |
original_received_at |
Original receipt time, including its time zone. |
intended_action |
Specific intended step, such as creating a handover card. |
manual_action_actual |
What actually happened; explicitly record “no action” where applicable. |
manual_action_at |
Time of the actual manual step; leave blank if there was no step. |
actor |
Person who performed the step; leave blank if there was no step. |
existing_destination_id |
Actual ID of a located result; leave blank when uncertain. |
verification_state |
State according to the rules below. |
evidence_reference |
Reference to verification, or evidence for a stop or uncertainty. |
owner |
Person responsible for the next review of this row. |
next_check_at |
Next review deadline for an open case, including the time zone. |
reconciliation_decision |
Decision after comparing the source, register, and destination. |
verified_at |
Time of completed verification; uncertainty gets no closure timestamp. |
Use text identifiers and timestamps such as 2026-10-17T09:10:00+02:00 in the CSV. Set ID columns to text when importing so that leading zeros, for example, are preserved. The template is not connected to any app and sends nothing.
3. Separate actions performed from confirmed results
“Create a card” is an intention. “Sent a create request; no response received” is an actual attempt with an uncertain result. “Opened CARD-202 with the matching request ID” is a verified finding.
Microsoft’s Retry pattern describes a service processing a request without delivering its response. A subsequent attempt can perform the operation again. A timeout alone therefore does not prove that no destination record was created. The documentation also does not establish that your particular integration supports safe retries.
Use these working states in the register. They are proposed codes, not Make or CRM system states. The English CSV retains the same codes as the Czech edition; the explanations below translate their meaning.
| State code | Meaning and next action |
|---|---|
cekajici |
Pending: source retained, no action performed yet. The owner checks the current need and destination. |
nejiste |
Uncertain: an attempt may have had an effect. Keep it open with an owner and review deadline; do not blindly create again. |
overeno_existuje |
Verified existing: the correct result was actually opened and matched to the request. A reference or next step may still be missing. |
zastaveno |
Stopped: there is evidence not to continue, such as cancellation. The maintainer must also handle any pending run. |
uzavreno |
Closed: source, result, and necessary references agree, and verification is recorded. |
Keep the original description of an attempt when new facts emerge. Add the decision and evidence; do not overwrite a timeout with a claim that no action occurred.
4. After recovery, reconcile three places
Before the maintainer resumes the affected workflow, the owner checks original source → manual register → restored destination. Counting rows is insufficient: two destination records may belong to one request while another request has no result at all.
First establish the end of the affected period. Review source events from the outage start through that point and verify that each has a row. Include teammates’ manual actions and events that changed or canceled a request. If the source does not allow a complete review of that period, record the gap and do not call the check complete.
Then work through each request in this order:
- Open the source and verify that the intended action still applies. A newer cancellation also matters for an older pending event.
- Read the actual manual actions and available information about pending runs.
- Search the destination for the specific request using its stable ID and supporting material. A matching client name is insufficient. An empty search result with uncertain scope or access is not proof of absence.
- Record the destination ID you found and your decision. Do not recreate a correct existing result; repair only the missing reference. If you cannot establish the result or the records conflict, leave the case open.
- After any repair, reopen the result. Save evidence and the verification time. The maintainer also checks that an old pending run will not repeat the same work later.
A missing result is not an automatic instruction to create a new one. First confirm the current need, authority for the next step, and the status of other attempts. For recovery of one particular run, continue with retrying safely after an error.
Five cases from one fictional outage
The example captures a fictional state after the first review. It does not show five successfully resolved items. DEMO: references are placeholders, not working evidence links. Role identifiers and timestamp offsets remain unchanged across editions.
| Request | Finding | Decision |
|---|---|---|
| REQ-101 | Source exists; nobody has acted yet. | Leave pending; check the destination and current need before taking another step. |
| REQ-102 | A teammate manually created CARD-202. The original register lacks its link. | Use the existing card and repair the reference. The case stays unclosed until then. |
| REQ-103 | Creation timed out; the result cannot yet be established. | Leave uncertain; the owner continues investigating without creating again. |
| REQ-104 | Same client as REQ-101, but a different request. | Retain separately and verify its own result. |
| REQ-105 | Source confirms cancellation. | Stop further work and have the maintainer handle the pending attempt. |
5. Resume with an explicit list of unresolved cases
Make’s scenario run replay documentation states that a full replay passes data through modules that already succeeded too. Replaying the entire period does not replace reconciliation of manual work against the destination. This behavior was checked in documentation on October 17, 2026, not through an account test.
Hand the register to the maintainer with a clear distinction between traceable results, missing references, stopped work, and uncertain cases. If you cannot exclude uncertain or stopped cases from further processing, leave the affected route paused. Changing a spreadsheet state alone does not block a pending run.
The period review is finished when each source event you could trace has a verified result, an intentional link to an existing result, a documented stop, or an open exception with an owner and deadline. Open exceptions stay open after service returns. Use the manual exception queue to manage them afterward.
This procedure needs no new AI agent. An optional comparison aid could prepare matches and missing references; it should not write to the destination or trigger replay itself. Matching IDs alone does not confirm correct contents or a still-valid request.
Sources and limits
The register design draws on a supplied research dossier dated September 27, 2026, particularly its proposed request tracking, handover checks, and partial-success handling. That internal dossier is not public user documentation, and its scenarios were not operationally tested. Public technical support comes from the Microsoft and Make documentation linked above, checked October 17, 2026.
The fields, state names, and fictional cases are editorial proposals. We have no measured time savings, test of your permissions, or proof of safe retries in your system. Use the register to decide from actual evidence; it cannot guarantee complete coverage of an unavailable source or safe concurrent writes.