Automatizace může přežít svůj původní účel
Tým změnil CRM, ale starý přenos pořád běží. Jiný report měsíce nikdo nečte. Úspěšné logy říkají, že se něco vykonává, ne že to stále někomu pomáhá.
Pravidelná revize spojí každou automatizaci s účelem, vlastníkem a závislostmi. Nejdřív zjistěte, co používá tým. Teprve potom rozhodujte o opravě, zjednodušení nebo vypnutí.
Použijte registr revize a plán vypnutí a smyšlený příklad. Může být součástí stejného dokumentu, ve kterém už evidujete procesy.
Ptejte se na současný přínos
Ke každému postupu napište spouštěč, vstupy, výstupy, poslední běh a člověka, který výsledky používá. Vlastníka odlište od původního autora. Pokud autor odešel, automatizace pořád potřebuje někoho, kdo řeší změny a výjimky.
Zkontrolujte, zda výstup vede k současnému kroku týmu. Report bez čtenáře může být kandidát k vypnutí; report používaný jednou za čtvrtletí nemusí být zbytečný jen proto, že ho tento týden nikdo neotevřel.
Rozhodnutí může znít: ponechat s potvrzeným vlastníkem, upravit kvůli změně procesu, sledovat do konkrétního data, nebo připravit vypnutí. Zapište důvod, ne pouze barevný stav.
Projděte závislosti v obou směrech
Zjistěte, co postup spouští a kdo používá jeho výsledek. Může existovat další scénář, ruční práce, externí webhook nebo klientské upozornění. Zvlášť projděte čekající, rozběhnuté a opakované úlohy. Poslední úspěšný běh jejich seznam nenahrazuje.
Přepnutí plánu není vždy vypnutí všech vstupů. Make popisuje režim On demand jako běh vyvolaný ručně nebo API voláním. Zrušení pravidelného rozvrhu tedy samo nedokazuje, že scénář nemůže běžet.
V konkrétním nástroji ověřte způsob zastavení a stav čekajících běhů. Návody a chování se liší. Nespoléhejte na obecné označení „neaktivní“ bez kontroly vstupní cesty.
Připravte náhradu a návrat
Než zastavíte přenos, určete, kdo přijme nové případy ručně nebo v nové cestě. Zachovejte konfiguraci a potřebné podklady podle dohodnutého režimu uchování, bez kopírování hesel do registru.
Napište čas vypnutí, kontrolní období a podmínku návratu. Návrat není jen znovu zapnout přepínač: během pauzy mohly vzniknout nové události. Před jejich zpracováním ověřte, které už někdo vyřešil ručně, aby se práce neopakovala.
Ve smyšleném příkladu vypínáme starý týdenní souhrn až po potvrzení nového reportu a jeho příjemce. Jeden celý týden sledujeme, zda nic nechybí. Pro jiný proces zvolte období podle četnosti a následků výpadku.
Oddělte zastavení od odstranění a nákladů
Postup nejdřív zastavte a kontrolujte jeho náhradu. Mazání konfigurace má jiný účinek a může ztížit návrat. U sdíleného účtu neodstraňujte oprávnění, které používají jiné automatizace.
Zkontrolujte i předplatné a dodatečné služby. Vypnutý scénář automaticky neruší placený plán; samostatně rozhodněte, co už není potřeba, kdo změnu provede a za jakých podmínek.
Začněte jedním postupem a jednou výslovnou kontrolou výsledku. Registr aktualizujte při větší změně procesu a v domluveném intervalu. Provozní přehled pak pomůže i při porovnání nákladů workflow.
Dokumentace ověřena 10. října 2026. Jde o připravený postup, nikoli již provedené vypnutí vašich služeb.
Konkrétní první vypnutí: pravidelný scénář v Make
Tuto variantu použijte jen pro jeden plánovaný scénář bez neprověřených vstupů. Na stránce detailu scénáře ověřte jeho název a ID a přepněte ON/OFF do neaktivního stavu podle návodu Make. Znovu načtěte detail a zaznamenejte stav i čas. Neaktivní scénář lze stále ručně spustit přes Run once; tým proto musí vědět, že je postup vyřazený. Nezaměňujte tuto změnu za úplný zákaz spuštění.
Před změnou vypište právě běžící a čekající běhy, webhooky, API a ruční vstupy. Neznámá cesta nebo nedořešený běh vypnutí blokuje, dokud vlastník neověří jeho bezpečné dokončení či konkrétní zastavení. Tento krok je kontrola rozvrhu; neobsahuje slib, že přepínač zruší všechny již spuštěné nebo čekající účinky.
Po změně sledujte nejbližší očekávané spuštění a náhradní výsledek. Pokud starý scénář přesto běží, vyřazení není hotové: zjistěte původ spuštění a další zápisy neopakujte naslepo. Konfiguraci zatím nemažte. Podrobnosti incidentu řeší oprava a návrat automatizace; zrušení placené služby je samostatné rozhodnutí.