Ten tekst jest dla osoby, która odpowiada za działanie firmy i ma w niej automatyzacje zbudowane w n8n, Make, Power Automate albo w kodzie — i zadaje sobie pytanie: co się stanie, gdy ktoś, kto to zbudował, odejdzie? To nie jest tekst o tym, czy budować samemu, czy z wykonawcą. Lista na końcu działa tak samo dla automatyzacji zbudowanej przez pracownika, przez freelancera i przez nas w ploch.ai. Zachowanie platform opisujemy na podstawie ich dokumentacji w stanie na 12 października 2026 r.; źródła są na końcu.
Automatyzacja to program, który psuje się po cichu
Automatyzacja bez kodu (no-code) wygląda jak ustawienie w narzędziu, ale działa jak każdy inny program. Łączy się z usługami przez API (interfejs, przez który inne programy łączą się z systemem i jego danymi), zależy od kont, haseł, cudzych systemów i wersji usług, które zmieniają się bez pytania Cię o zdanie. Jeśli wie o niej tylko osoba, która ją zbudowała, ma jednego opiekuna — i nikt inny nie wie, że w ogóle istnieje.
Do tego automatyzacja rzadko psuje się głośno. Nie pojawia się czerwony ekran. Faktury po prostu przestają trafiać do systemu księgowego, a ktoś zauważa to przy zamknięciu miesiąca.
Siedem sposobów, na jakie automatyzacja cicho przestaje działać
Tabela jest kręgosłupem tego tekstu. Kolumna „kto zwykle zauważa” opisuje sytuację bez przygotowanego przekazania. „Wykonawca” to rola, nie firma: osoba, która naprawia i testuje — pracownik, freelancer albo firma zewnętrzna. Nakład naprawy opisujemy trzema poziomami: mały — odnowienie dostępu albo zmiana ustawienia, bez zmian w krokach automatyzacji; średni — poprawka wybranego kroku; duży — przebudowa kilku kroków albo ponowna ocena całego procesu na prawdziwych przypadkach. Po każdej naprawie sprawdza się wynik całego procesu; zakres testu zależy od tego, na co zmiana wpływa.
| Awaria | Objaw | Kto zwykle zauważa | Kto działa | Nakład naprawy |
|---|---|---|---|---|
| 1. Wygasły lub cofnięty dostęp | Kroki łączące się z usługą zwracają błąd uprawnień | Ten, komu brakuje danych na końcu procesu | Osoba od systemów | Mały: ponownie podłączyć konto i sprawdzić jeden przebieg |
| 2. Automatyzacja wyłączona przez platformę lub po przeniesieniu | Nic się nie dzieje — brak błędów, bo brak przebiegów | Ten, komu brakuje danych na końcu procesu | Wykonawca | Mały do średniego: usunąć przyczynę, sprawdzić, co zostało zrobione częściowo, dopiero potem włączyć i nadrobić zaległości |
| 3. Zmiana w API połączonego systemu | Błędy w jednym kroku albo puste pola w wyniku | Odbiorca powiadomień o błędach — jeśli je ustawiono | Wykonawca | Średni: poprawić połączenie i przetestować proces |
| 4. Wycofana wersja modelu AI | Błąd po dacie wycofania; przed nią — inny wynik po zmianie modelu | Osoba, która założyła konto — jeśli dostawca wysyła ostrzeżenie mailem | Wykonawca z właścicielem procesu | Duży: przetestować proces od nowa na nowym modelu |
| 5. Wyczerpany limit planu lub zmiana cennika | Zależnie od platformy i planu: przebiegi wstrzymane, dopóki ktoś nie zwiększy limitu, opłaty za dodatkowe zużycie albo wyższa opłata za plan | Ten, komu brakuje danych, albo księgowość przy kontroli kosztów | Osoba od systemów | Mały do średniego: zmienić plan albo ograniczyć zużycie |
| 6. Nowy układ dokumentu lub danych wejściowych | Puste albo przesunięte pola, choć przebieg „się udał” | Właściciel procesu, przy ręcznej kontroli | Wykonawca | Średni: dostosować odczyt i dodać przykład do testów |
| 7. Spadek jakości bez żadnego błędu | Coraz więcej poprawek ręcznych, odpowiedzi „prawie dobre” | Właściciel procesu — jeśli mierzy | Właściciel procesu z wykonawcą | Średni do dużego: sprawdzić próbkę wyników, poprawić instrukcje lub reguły i przetestować |
Poniższe szczegóły rozstrzygają, czy dana awaria zostanie zauważona w godzinę, czy w kwartał.
1. Dostęp wygasa z powodów, których nikt nie planuje. Automatyzacja przechowuje dostęp do usług — hasło, klucz albo token, czyli cyfrową przepustkę wydaną przez usługę. Przy kontach Google często jest to token odświeżania: przepustka, dzięki której automatyzacja odnawia dostęp bez ponownego zatwierdzania połączenia. Google wymienia w dokumentacji powody, dla których token odświeżania przestaje działać, między innymi: użytkownik cofnął dostęp, token nie był używany przez sześć miesięcy albo użytkownik zmienił hasło i dostęp obejmuje Gmaila. Aplikacja skonfigurowana w Google Cloud dla użytkowników spoza organizacji, ze statusem publikacji „Testing”, dostaje token ważny siedem dni, chyba że prosi tylko o podstawowe dane profilu. Automatyzacja podłączona na szybko „na chwilę” potrafi więc przestać działać po tygodniu.
2. Platforma potrafi sama wyłączyć automatyzację. W Make ustawia się, ile błędów z rzędu scenariusz może popełnić, zanim zostanie wyłączony, ale scenariusz uruchamiany natychmiastowym wyzwalaczem — krokiem, który startuje scenariusz od razu po otrzymaniu zdarzenia, na przykład webhooka, czyli automatycznego powiadomienia z innego systemu — jest wyłączany już po pierwszym błędzie, którego nie przechwyci ustawiona w scenariuszu obsługa błędów. W n8n samo przeniesienie automatyzacji do innej instalacji przez kontrolę wersji (zapis kolejnych wersji automatyzacji poza n8n) nie gwarantuje, że zacznie działać: po stronie docelowej trzeba sprawdzić, czy publikacja — ręczna albo automatyczna przy pobieraniu zmian — się udała, bo może się nie udać, na przykład gdy brakuje dostępów. Wyłączona automatyzacja nie generuje błędów — dlatego taką awarię łatwo przeoczyć.
3. Systemy, z którymi automatyzacja się łączy, zmieniają API. Przykład z ostatnich tygodni:
Microsoft usunął wersję 1.0 API systemu Business Central w pierwszej fali wydań 2026 r. (wersja
28.0 i nowsze). Make opublikował 18 września 2026 r. komunikat, że scenariusze z połączeniami
ręcznie ustawionymi na adres /api/v1.0/ przestaną działać, i trzeba je przestawić na
/api/v2.0/. Komunikat trafił do centrum pomocy Make — ktoś musiał go przeczytać.
4. Dostawcy wycofują wersje modeli. Czym to grozi i dlaczego trzeba wtedy testować od nowa, opisaliśmy w tekście o tym, ile kosztuje wdrożenie AI. Tu liczy się jedno: kto dostanie ostrzeżenie i ile ma czasu.
| Dostawca | Wyprzedzenie przed wycofaniem i sposób powiadomienia (stan na 12 października 2026 r.) |
|---|---|
| OpenAI | co najmniej 6 miesięcy dla modeli ogólnie dostępnych i co najmniej 3 miesiące dla ich wyspecjalizowanych wariantów; modele w wersji podglądowej (preview) mogą zostać wycofane znacznie szybciej — OpenAI podaje przykład 2 tygodni; szybciej także ze względów bezpieczeństwa lub zgodności; mail do aktywnych klientów i wpis w dokumentacji |
| Anthropic | co najmniej 60 dni dla modeli udostępnionych publicznie; mail i wpis w dokumentacji |
| Google (Gemini API) | daty w tabeli Google są najwcześniejszymi możliwymi terminami; dokładną datę Google ogłasza z wyprzedzeniem |
Jeśli dostawca wysyła ostrzeżenie mailem, a konto założył autor automatyzacji na swój adres, ostrzeżenie trafi do osoby, której w firmie już nie ma.
5. Limit planu albo cennik zmienia się w trakcie roku. Make rozlicza się w kredytach; gdy się skończą, można zmienić plan, kupić dodatkowe kredyty albo włączyć ich automatyczny zakup. Make pisze, że automatyczny zakup ma utrzymać scenariusze w ruchu po wyczerpaniu limitu; dodatkowe kredyty kosztują o 25% więcej niż kredyty w planie. W n8n w planach Business i Enterprise automatyzacje działają dalej po przekroczeniu limitu wykonań, ale może zostać doliczona opłata za nadwyżkę. Oba przypadki widać dopiero na fakturze, jeśli nikt nie patrzy na zużycie. Sama zmiana cennika nie zatrzymuje automatyzacji, ale zmienia rachunek, na którym opierała się decyzja o jej budowie — dlatego trafia do tej samej tabeli.
6 i 7. Nowy układ dokumentu i spadek jakości to awarie bez błędu. Platforma uznaje przebieg za udany, bo każdy krok się wykonał — tyle że w polu „kwota” wylądowała data. Takie awarie wykrywa człowiek, który zna proces, albo reguła sprawdzająca wynik — o ile da się ją zapisać, na przykład „suma netto i VAT równa się kwocie brutto”. W n8n taka reguła kieruje przebieg do kroku Stop and Error, który oznacza przebieg jako nieudany; wtedy uruchamia się przypisana automatyzacja obsługi błędów i wysyła powiadomienie. Jeśli proste reguły nie wystarczają do oceny jakości, potrzebny jest człowiek sprawdzający próbkę wyników; automatyczne kontrole mogą ten przegląd jedynie wspierać. Jak to zaplanować, opisaliśmy w tekście o nadzorze człowieka nad automatyzacją.
Gdy autor odchodzi: dlaczego nic nie zostaje naprawione
Odejście autora nie jest ósmą awarią. Jest powodem, dla którego każda z siedmiu kończy się dłuższym przestojem, bo nikt nie wie, gdzie szukać. Do tego dochodzą trzy pułapki opisane w dokumentacji platform:
- Połączenia zależne od konta autora. W Make osoba usuwająca swój profil wybiera, czy usunąć także połączenia, które założyła. Jeśli je usunie, wszystkie scenariusze, które z nich korzystają, przestają działać. Połączenie podłączone do prywatnego konta Google czy Microsoft zależy dodatkowo od tego, czy to konto nadal istnieje i czy firma ma nad nim jakąkolwiek kontrolę.
- Przepływ bez właściciela. Microsoft opisuje w Power Automate przepływy, które po odejściu właściciela nie mają ważnego właściciela i mogą przestać działać, jeśli korzystają z połączeń przypisanych do jego konta. Po odejściu właściciela przepływ przechodzi na niższą wydajność. FAQ dotyczące licencji Power Automate dodaje, że właściciele dostają wtedy powiadomienie, a jeśli nikt nie podejmie działania, przepływ zostaje wyłączony po 14 dniach. Niezależnie od tego strona Microsoftu o limitach opisuje wyłączanie po 14 dniach przepływów, w których wyzwalacz lub kroki bez przerwy kończą się błędem albo które platforma stale spowalnia, bo przekraczają limity. Po odejściu właściciela warto od razu sprawdzić, czy przepływ działa poprawnie. Administrator może wskazać nowego współwłaściciela, ale to dopiero początek: trzeba też sprawdzić połączenia i licencję, na której przepływ działa.
- Powiadomienia na skrzynkę, której nikt nie czyta. Błędy, ostrzeżenia o wycofaniu modeli i komunikaty o zmianach API trafiają tam, gdzie wskazał je autor.
W n8n przy przenoszeniu automatyzacji przez kontrolę wersji n8n ustala właściciela na podstawie adresu e-mail; jeśli tej osoby nie ma w docelowej instalacji, właścicielem zostaje ten, kto przenosi.
Kto za co odpowiada po uruchomieniu
W przewodniku jak wdrożyć AI w firmie jest tabela ról na czas projektu. Poniższa dotyczy czasu po uruchomieniu — miesięcy i lat, w których nikt już nie myśli o automatyzacji jak o projekcie.
| Zadanie po uruchomieniu | Właściciel procesu | Osoba od systemów | Wykonawca |
|---|---|---|---|
| Sprawdza próbkę wyników i zgłasza spadek jakości | odpowiada | — | pomaga ustalić przyczynę |
| Pilnuje dostępów, kont i ich odnowienia | — | odpowiada | wskazuje, które dostępy są potrzebne |
| Śledzi zmiany w połączonych systemach i komunikaty dostawców | — | odpowiada | ocenia wpływ i poprawia |
| Testuje proces po zmianie modelu lub systemu | zatwierdza wynik testu | — | przeprowadza test |
| Decyduje o wyłączeniu automatyzacji | odpowiada | doradza w sprawie kosztów | doradza w sprawie nakładu pracy |
| Pilnuje budżetu na utrzymanie | odpowiada | dostarcza dane o zużyciu | szacuje godziny |
W małej firmie trzy kolumny łączy jedna lub dwie osoby i to jest w porządku — byle każda komórka oznaczona „odpowiada” miała imię i nazwisko.
Co musi zostać w firmie: lista przekazania
Ta lista ogranicza zależność od autora i pozwala firmie przejąć kontrolę nad automatyzacją. Techniczne minimum dla n8n na własnym serwerze — klucz szyfrowania przechowywany poza serwerem, przetestowane odtworzenie z kopii zapasowej i aktualizacje — opisaliśmy w przewodniku po n8n i nie powtarzamy go tutaj. Poniżej to, co obowiązuje na każdej platformie.
- Spis automatyzacji z właścicielem biznesowym każdej z nich. Nazwa, co robi, z jakimi systemami się łączy, kto w firmie odpowiada za wynik. Automatyzacja bez właściciela w spisie to pierwsza kandydatka do wyłączenia.
- Spis dostępów na kontach kontrolowanych przez firmę. Każde połączenie z inną usługą założone na koncie, nad którym firma ma kontrolę — tam, gdzie platforma na to pozwala, na koncie technicznym (służbowym koncie założonym dla systemu, a nie dla konkretnej osoby), a nie na prywatnym koncie pracownika. Dla połączeń, które muszą być przypisane do konkretnej osoby, opisana i sprawdzona procedura ich podmiany. Przy każdym dostępie, który wygasa, data ważności.
- Adres kontaktowy u dostawców na wspólną skrzynkę. Konta w platformie i u dostawców modeli z adresem do powiadomień, który czyta więcej niż jedna osoba — niezależnie od tego, na czyje konto automatyzacja się łączy.
- Eksport i historia wersji. Aktualna kopia każdej automatyzacji poza platformą — szczegóły dla trzech platform w tabeli niżej. Przy zapisie przez Git (system zapisujący kolejne wersje plików) w n8n sprawdź też, czy przekazywana wersja odpowiada tej działającej na co dzień: ostatnia zapisana wersja może zawierać jeszcze nieopublikowane zmiany.
- Powiadomienia na wspólny kanał — także o tym, że czegoś nie było. Na każdej platformie powiadomienie o błędzie trafia na kanał zespołu, a nie do jednej osoby, i ma kogoś, kto je potwierdza i przekazuje dalej. W n8n służy do tego automatyzacja obsługi błędów zaczynająca się od kroku Error Trigger, przypisana do każdej automatyzacji działającej na co dzień; jedna może obsługiwać wiele automatyzacji. Ponieważ wyłączona automatyzacja nie zgłasza błędów, potrzebna jest też kontrola oczekiwanego wyniku działająca niezależnie od niej: na przykład codzienne podsumowanie liczby przebiegów, w którym alarmem jest zarówno zero w dniu, w którym spodziewano się pracy, jak i brak samego podsumowania.
- Reguły sprawdzające wynik. Tam, gdzie błędny wynik nie powoduje błędu (wiersze 6 i 7 tabeli), a warunek poprawności da się zapisać, automatyzacja sprawdza wynik sama i oznacza przebieg jako nieudany. Pozostałe przypadki sprawdza człowiek na próbce.
- Przetestowane odtworzenie. Kopia zapasowa, z której ktoś w firmie faktycznie odtworzył automatyzację — razem z dostępami.
- Świadomie ustalony zapis i czas przechowywania danych z przebiegów. Sprawdź, jakie dane z przebiegów zapisuje platforma albo kod, gdzie je przechowuje i jakie ustawienia ograniczają ich zapis i czas przechowywania — to decyzja do podjęcia dla każdej automatyzacji. Jak wygląda to w n8n i co z tego wynika dla RODO (ogólnego rozporządzenia o ochronie danych), opisaliśmy w przewodniku po n8n.
- Sprawdzona licencja. Na czyjej licencji działa automatyzacja i czy licencja pozwala na sposób, w jaki jest używana. W Power Automate przepływ uruchamiany automatycznie albo według harmonogramu działa na licencji właściciela, chyba że ma przypisaną osobną licencję Process; w n8n warunki darmowej edycji opisuje licencja Sustainable Use.
- Jednostronicowa instrukcja dla każdej automatyzacji. Co robi, skąd bierze dane, dokąd je wysyła, kto ją zatwierdza, jak poznać, że przestała działać, jak ją bezpiecznie wyłączyć i jak nadrobić zaległe przebiegi bez tworzenia podwójnych wpisów.
Eksport i wersje: n8n, Make, Power Automate
| Platforma | Co da się zrobić bez płatnych dodatków | Co jest płatne lub ograniczone | Czego eksport nie zawiera |
|---|---|---|---|
| n8n | Pobranie automatyzacji jako pliku JSON (tekstowego zapisu wszystkich kroków i ustawień); historia wersji z ostatnich 24 godzin | Kontrola wersji przez Git w planie Business na własnym serwerze i w planie Enterprise; historia z 5 dni w n8n Cloud Pro, pełna w Enterprise | Zapisanych dostępów — plik ma tylko ich nazwy i identyfikatory; przy Git przenoszone są „zaślepki” dostępów (identyfikator, nazwa, typ), a inne pola tylko wtedy, gdy są formułami (tzw. wyrażeniami) — dlatego to, co n8n zapisuje w Git, trzeba przejrzeć i trzymać w miejscu niedostępnym publicznie |
| Make | Eksport scenariusza jako blueprintu, czyli pliku z opisem kroków, ustawień i przypisania danych do pól; zapisywanie wersji scenariusza i przywracanie ich z historii (we wszystkich planach) | Zapisana wersja jest przechowywana 60 dni, z wyjątkiem ostatniej, którą Make trzyma do czasu zapisania nowszej | Połączeń: po imporcie trzeba je założyć na nowo |
| Power Automate | Eksport rozwiązania (solution, czyli paczki z przepływem i powiązanymi elementami) jako pliku ZIP | Zmianę głównego właściciela da się wykonać tylko dla przepływu w rozwiązaniu; przepływ spoza rozwiązania współwłaściciel musi najpierw do niego dodać albo wyeksportować i zaimportować jako nowy | Połączeń: rozwiązanie zawiera odwołania do połączeń, a przy imporcie wskazuje się połączenia w środowisku docelowym |
Dwa wnioski. Po pierwsze, sam eksport nie wystarcza do odtworzenia dostępów — dlatego punkt 2 listy jest równie ważny jak punkt 4. Po drugie, „bez dostępów” nie znaczy „bez tajemnic”: n8n ostrzega, że krok HTTP Request (wysyłający zapytanie do innego systemu), utworzony przez wklejenie gotowego polecenia, może mieć w ustawieniach hasło albo klucz skopiowane razem z tym poleceniem. Plik eksportu n8n może też zawierać dane przypięte do kroków, czyli zapisane przy nich do ponownego użycia podczas testów. Mogą to być prawdziwe dane klientów. Zanim udostępnisz eksport komuś spoza firmy, sprawdź, czy ustawienia kroków nie zawierają haseł ani kluczy, a przypięte dane oraz nazwy zapisanych dostępów (bywa w nich na przykład nazwa klienta) usuń albo zanonimizuj.
Gdy zmienia się model w kroku AI: co sprawdzić ponownie
Zmiana modelu — wymuszona wycofaniem albo wybrana dla niższej ceny — to zmiana programu, nawet jeśli w automatyzacji zmienia się jedno pole. Przed przełączeniem warto sprawdzić:
- wyniki na tej samej próbce prawdziwych przypadków, na której automatyzację odbierano, w tym na przypadkach trudnych i nietypowych;
- format odpowiedzi — czy następne kroki dostają pola w tym samym układzie;
- odsetek przypadków kierowanych do człowieka;
- koszt jednego przebiegu po zmianie.
Wycofania nie da się przesunąć, ale da się je zaplanować: wyprzedzenie z tabeli wyżej to czas na test, pod warunkiem że ostrzeżenie trafia do właściwej osoby.
Co dopisać do rocznego budżetu
Nie podajemy kwot, bo zależą od procesu. Podajemy wzory i miejsca, z których bierze się liczby. Kategorie kosztów bieżących opisaliśmy w tekście ile kosztuje wdrożenie AI, a pełny rachunek na dwanaście miesięcy dla agenta AI (programu, który sam wykonuje kolejne kroki zadania w Twoich systemach) — w tekście ile kosztuje agent AI.
| Pozycja | Wzór na rok | Skąd wziąć liczby |
|---|---|---|
| Platforma | miesięczna cena planu × 12 + opłaty za zużycie ponad limit | Cennik platformy i panel zużycia (wykonania w n8n, kredyty w Make) |
| Model AI | wywołania w miesiącu × średni koszt wywołania × 12 — bez wywołań, których koszt użycia modelu jest już zawarty w kredytach platformy (np. przy wbudowanym dostawcy AI w Make) | Cennik dostawcy i rachunki z kilku miesięcy |
| Sprawdzanie jakości | godziny w miesiącu × 12 × stawka osoby sprawdzającej | Czas właściciela procesu na przegląd próbki wyników |
| Testy po zmianie modelu | liczba zmian modelu w roku × godziny jednego testu × stawka | Strony dostawców o wycofywaniu modeli i czas jednego testu |
| Poprawki po zmianach w systemach | dla każdego połączonego systemu: spodziewane zmiany w roku × godziny poprawki × stawka | Komunikaty dostawców tych systemów |
| Odnawianie dostępów | liczba odnowień w roku × godziny jednego odnowienia × stawka | Spis dostępów z punktu 2 listy |
| Obsługa powiadomień i awarii | godziny w miesiącu na potwierdzanie powiadomień, ustalanie przyczyn, obsługę wyjątków i nadrabianie zaległych przebiegów × 12 × stawka | Historia powiadomień i awarii z ostatnich miesięcy albo szacunek wykonawcy |
| Własny serwer (jeśli dotyczy) | (miesięczny koszt serwera + miesięczny koszt kopii zapasowych) × 12 + godziny aktualizacji i testów odtworzenia w roku × stawka | Rachunki za serwer i przechowywanie kopii oraz czas administratora |
Każdą godzinę pracy przypisz do jednej pozycji, żeby nie policzyć jej dwa razy. Gdy pozycje są wpisane, widać też, czy automatyzacja się opłaca.
Kiedy utrzymanie oznacza wyłączenie automatyzacji
Automatyzację warto wyłączyć, gdy roczna suma z tabeli przekracza wartość czasu, który oszczędza, albo gdy nie ma właściciela procesu, który odpowie, czy wynik jest poprawny. To ta sama reguła, którą stosujemy przed budową: „oszczędność nie pokrywa utrzymania” to jeden z powodów, dla których odmawiamy projektu. Wyłączenie też jest decyzją do zaplanowania: kto przejmuje pracę ręcznie, co z danymi z przebiegów i które dostępy trzeba cofnąć.
Audyt w jedno popołudnie: dziesięć pytań
Te pytania może zadać osoba zarządzająca, bez czytania kodu. Każda odpowiedź „nie wiem” to pozycja do uzupełnienia.
- Czy mamy spis wszystkich automatyzacji, łącznie z tymi zbudowanymi „na chwilę”?
- Czy każda ma właściciela biznesowego z imienia i nazwiska?
- Czy któreś połączenie zależy od prywatnego konta pracownika albo od konta, nad którym firma nie ma kontroli?
- Na jaki adres przychodzą maile od platformy i od dostawców modeli?
- Gdzie trafia powiadomienie, gdy automatyzacja zakończy się błędem — i kto je ostatnio widział?
- Czy któraś automatyzacja jest wyłączona, a nikt tego nie zauważył?
- Czy mamy aktualny eksport każdej automatyzacji poza platformą?
- Czy ktoś kiedykolwiek odtworzył automatyzację z kopii zapasowej?
- Ile w zeszłym roku kosztowała platforma i model — i czy ktoś to porównał z oszczędzonym czasem?
- Czy dla każdej automatyzacji istnieje jednostronicowa instrukcja, z której skorzysta osoba, która jej nie budowała?
Jak przekazujemy kod, konfigurację i dokumentację po wdrożeniu, opisuje metodyka wdrożenia; jak wygląda cały projekt automatyzacji od wyboru procesu do utrzymania — strona o automatyzacji AI w firmie.
Źródła i stan na 12 października 2026 roku
- n8n Docs — obsługa błędów (Error Trigger, Stop and Error); odczyt 12 października 2026 r.
- n8n Docs — kontrola wersji i środowiska oraz wysyłanie i pobieranie zmian — dostępność w planach Business i Enterprise, zaślepki dostępów, publikacja i właściciel po przeniesieniu; odczyt 12 października 2026 r.
- n8n Docs — eksport i import i historia zmian oraz przypinanie danych; odczyt 12 października 2026 r.
- Cennik n8n — plany, kontrola wersji przez Git w planie Business, opłaty za nadwyżkę w planach Business i Enterprise; odczyt 12 października 2026 r.
- FAQ licencji n8n — licencja Sustainable Use; odczyt 12 października 2026 r.
- Make Help Center — ustawienia scenariusza (wyłączenie po błędach), blueprinty, wersje scenariusza (dostępność we wszystkich planach według komunikatu Make), usuwanie profilu, kredyty i dodatkowe kredyty; odczyt 12 października 2026 r.
- Make Help Center — Business Central: wymagane działanie dla połączeń z API v1.0 — komunikat z 18 września 2026 r.; odczyt 12 października 2026 r.
- Microsoft Learn — przepływy bez właściciela po jego odejściu, zmiana właściciela przepływu, FAQ licencji Power Automate, limity przepływów, eksport rozwiązania i odwołania do połączeń; odczyt 12 października 2026 r.
- Google for Developers — OAuth 2.0, wygasanie tokenów odświeżania; odczyt 12 października 2026 r.
- OpenAI — wycofywanie modeli, Anthropic — wycofywanie modeli i Gemini API — wycofywanie modeli; odczyt 12 października 2026 r.