Pro každou událost z doby výpadku dohledáte ověřený výsledek, zastavení nebo neuzavřenou výjimku s vlastníkem.
Poptávky dál přicházejí, ale aplikace pro předání práce neodpovídá. Kolega něco vyřídí ručně, jiný čeká a u třetího pokusu není jasné, zda se zakázka vůbec vytvořila. Po obnově služby potřebujete zjistit, co už je hotové a co ještě čeká.
Založte jednu dočasnou evidenci pro dobu výpadku. U každé zdrojové události oddělte, co se mělo stát, co člověk skutečně udělal a co jste ověřili v cíli. Nejasný výsledek ponechte otevřený. Návod vás provede od založení seznamu po kontrolu před obnovením automatizace. Samotnou službu neobnoví.
Použijte prázdnou evidenci v CSV a pět vyplněných modelových případů. Jde o návrh postupu a smyšlená data, nikoli o výsledky testování ve vašich účtech.
1. Určete jednu evidenci, vlastníka a začátek výpadku
Použijte stávající pracovní seznam s omezeným přístupem, který je během výpadku dostupný vlastníkovi a zástupci. Pokud je nedostupný i on, určete jedno dostupné schválené místo pro dočasný seznam. Nezakládejte paralelní kopii u každého kolegy. Jestliže nemáte dostupné místo pro bezpečnou evidenci nebo nevidíte původní zdroj, ponechte dotčené případy nerozhodnuté; tento postup dostupnost dat neobnoví.
Do záhlaví incidentu zapište:
- ID incidentu a začátek dotčeného období včetně časového pásma;
- zdroj příchozích požadavků, nedostupný cíl a dotčenou automatizaci;
- vlastníka evidence, jeho zástupce a čas další společné kontroly;
- kdo smí dělat ruční změny a kdo ověří čekající automatické pokusy.
Správce musí zjistit, zda se některé běhy ještě opakují nebo čekají na obnovení. Domluva mezi kolegy sama automatické pokusy nezastaví. Dokud jejich stav neznáte, u případu s nejistým výsledkem nic znovu nevytvářejte.
Dočasný seznam obsahuje jen potřebné identifikátory, stav a odkazy. Podrobné podklady ponechte v původním omezeném zdroji. Vlastník i zástupce potřebují skutečný přístup k podkladům; samotný odkaz v tabulce nestačí.
2. Zapište událost dřív, než ji začnete ručně vyřizovat
Jeden řádek představuje jednu zdrojovou událost. Zachovejte její původní ID i ID požadavku. Více událostí může patřit ke stejnému požadavku: například přijetí a pozdější zrušení. Při kontrole je proto projděte společně a zachovejte informaci o tom, co se každou událostí změnilo. Dvě různé poptávky od stejného klienta neslučujte podle e-mailu.
Když zdroj nemá stálé ID, přidělte dočasné označení a připojte dohledatelný originál. Označení samo neprokazuje shodu s cílem; tu bude muset někdo posoudit. Uchovejte původní čas přijetí. Čas ručního vyřízení patří do jiného pole.
Šablona používá následující pole. Technické názvy v CSV zůstávají stabilní pro případné pozdější porovnání.
| Pole v CSV | Co zapsat |
|---|---|
incident_id |
Společné ID výpadku. |
source_event_id |
ID konkrétní zdrojové události. |
request_id |
ID požadavku, ke kterému událost patří. |
source_reference |
Dohledatelný originál v omezeném zdroji. |
original_received_at |
Původní přijetí včetně pásma. |
intended_action |
Konkrétní zamýšlený krok, například založení předávací karty. |
manual_action_actual |
Co se skutečně udělalo; případně výslovně „žádná akce“. |
manual_action_at |
Čas skutečného ručního kroku; bez kroku nechte prázdné. |
actor |
Kdo krok provedl; bez kroku nechte prázdné. |
existing_destination_id |
Skutečné ID nalezeného výsledku; při nejistotě prázdné. |
verification_state |
Stav podle níže uvedených pravidel. |
evidence_reference |
Odkaz na ověření, případně podklad k zastavení či nejistotě. |
owner |
Kdo odpovídá za další kontrolu tohoto řádku. |
next_check_at |
Termín další kontroly otevřeného případu včetně pásma. |
reconciliation_decision |
Rozhodnutí po porovnání zdroje, evidence a cíle. |
verified_at |
Čas dokončeného ověření; nejistota sem datum uzavření nedostane. |
V CSV používejte textové identifikátory a datum ve tvaru 2026-10-17T09:10:00+02:00. Při importu nastavte sloupce s ID jako text, aby se například neztratily úvodní nuly. Šablona není napojená na žádnou aplikaci a nic neodesílá.
3. Oddělte provedenou práci od potvrzeného výsledku
„Vytvořit kartu“ je záměr. „Odeslán požadavek na vytvoření, odpověď nedorazila“ je skutečný pokus s nejistým výsledkem. „Otevřena karta CARD-202 s odpovídajícím ID požadavku“ je ověřený nález.
Microsoft v návrhovém vzoru Retry popisuje situaci, kdy služba požadavek zpracuje, ale odpověď nedoručí. Další pokus pak může operaci provést znovu. Timeout tedy sám neprokazuje, že cílový záznam nevznikl. Dokumentace současně nedokládá, že vaše konkrétní propojení umí bezpečné opakování.
Pro evidenci si zvolte tyto pracovní stavy; nejsou to systémové stavy Make ani vašeho CRM:
| Stav | Význam a další krok |
|---|---|
cekajici |
Zdroj je zachován, nic se zatím neprovedlo. Vlastník ověří aktuální potřebu a cíl. |
nejiste |
Pokus mohl mít účinek. Zůstává otevřený s vlastníkem a termínem; žádné slepé vytvoření. |
overeno_existuje |
Správný výsledek byl skutečně otevřen a přiřazen k požadavku. Ještě může chybět odkaz nebo další krok. |
zastaveno |
Je doložen důvod nepokračovat, například zrušení. Správce musí ošetřit i čekající běh. |
uzavreno |
Zdroj, výsledek i potřebné odkazy souhlasí a je zapsáno ověření. |
Při novém zjištění zachovejte původní popis pokusu. Doplňte rozhodnutí a důkaz; nepřepište timeout tvrzením, že žádná akce neproběhla.
4. Po obnově porovnejte tři místa
Než správce obnoví dotčený tok, vlastník projde původní zdroj → dočasnou evidenci → obnovený cíl. Nestačí spočítat řádky: dva cílové záznamy mohou patřit jednomu požadavku a jiný může úplně chybět.
Nejdřív vymezte konec dotčeného období. Ve zdroji projděte události od začátku výpadku do tohoto okamžiku a ověřte, že každá má řádek. Zahrňte ruční kroky kolegů i události o změně nebo zrušení. Pokud zdroj neumožňuje úplné dohledání tohoto období, zapište mezeru a neoznačujte kontrolu za úplnou.
Potom projděte každý požadavek v tomto pořadí:
- Otevřete zdroj a ověřte, že zamýšlená akce stále platí. Novější zrušení má význam i pro starší čekající událost.
- Přečtěte skutečné ruční kroky a dostupné údaje o čekajících bězích.
- V cíli vyhledejte konkrétní požadavek podle stálého ID a podkladu. Shoda jména klienta nestačí. Prázdný výsledek hledání bez jistoty o rozsahu a přístupu není důkaz neexistence.
- Zapište nalezené cílové ID a rozhodnutí. Existující správný výsledek znovu nevytvářejte; opravte pouze chybějící vazbu. Pokud výsledek nelze určit nebo se údaje rozcházejí, ponechte případ otevřený.
- Po případné opravě výsledek znovu otevřete. Uložte důkaz a čas kontroly. Správce zároveň ověří, že starý čekající běh stejnou práci později nezopakuje.
Chybějící výsledek není automatický příkaz k novému vytvoření. Nejdřív musí být potvrzená současná potřeba, oprávnění k dalšímu kroku a stav ostatních pokusů. Pokud potřebujete opravit jeden konkrétní běh, pokračujte návodem bezpečné opakování po chybě.
Pět případů ze stejného modelového výpadku
Přiložený příklad zachycuje smyšlený stav po první kontrole. Nejde o pět úspěšně vyřešených položek.
| Požadavek | Zjištění | Rozhodnutí |
|---|---|---|
| REQ-101 | Zdroj existuje, nikdo zatím nic nedělal. | Nechat čekající; ověřit cíl i současnou potřebu před dalším krokem. |
| REQ-102 | Kolega ručně založil CARD-202. V původní evidenci chybí odkaz. | Použít existující kartu a opravit vazbu. Do té doby nejde o uzavřený případ. |
| REQ-103 | Vytvoření skončilo timeoutem, výsledek zatím nelze určit. | Nechat nejisté; vlastník pokračuje v dohledání, nic znovu nevytváří. |
| REQ-104 | Stejný klient jako u REQ-101, ale jiný požadavek. | Uchovat samostatně a ověřit samostatný výsledek. |
| REQ-105 | Zdroj potvrzuje zrušení. | Zastavit další práci a se správcem ošetřit čekající pokus. |
5. Obnovte tok s výslovným seznamem nevyřešených případů
V dokumentaci Make k přehrání běhu je uvedeno, že data při plném přehrání procházejí i moduly, které už uspěly. Plošné přehrání období proto nenahrazuje porovnání ruční práce s cílem. Tato vlastnost byla ověřena v dokumentaci 17. října 2026, nikoli pokusem v účtu.
Správci předejte evidenci s jasným rozlišením: co má dohledatelný výsledek, kde se jen doplňuje odkaz, co je zastavené a co zůstává nejisté. Pokud nejisté či zastavené případy neumíte od dalšího zpracování oddělit, dotčenou cestu zatím neobnovujte. Pouhé přepsání stavu v tabulce žádný čekající běh neblokuje.
Kontrola období je dokončená, když každá dohledaná zdrojová událost končí ověřeným výsledkem, záměrným odkazem na existující výsledek, doloženým zastavením nebo otevřenou výjimkou s vlastníkem a termínem. Otevřené výjimky zůstávají otevřené i po obnově služby. Pro jejich další provoz použijte frontu ruční kontroly.
Tento postup nevyžaduje nového AI agenta. Případná pomůcka pro porovnání může připravit shody a chybějící reference; nemá sama zapisovat do cíle ani spouštět přehrání. Samotná shoda ID nepotvrzuje správnost obsahu nebo platnost zadání.
Podklady a hranice postupu
Návrh evidence vychází z dodaného výzkumného podkladu z 27. září 2026, zejména z návrhu evidence požadavků, kontroly předání a řešení částečného úspěchu. Tento interní podklad není veřejná uživatelská dokumentace a jeho scénáře nebyly provozně otestované. Veřejně přístupné technické opory jsou výše odkazované dokumentace Microsoft a Make, zkontrolované 17. října 2026.
Pole, názvy stavů a modelové případy jsou redakční návrh. Nemáme měření úspory, test vašich oprávnění ani důkaz bezpečného opakování ve vašem systému. Použijte evidenci k rozhodnutí podle skutečných podkladů; úplnost nedostupného zdroje ani bezpečné souběžné zápisy za vás nezaručí.