Dlaczego automatyzacje Make nie działają? Diagnoza scenariusza krok po kroku

Najpierw ustal, na którym etapie znika oczekiwany efekt. Brak wykonania kieruje uwagę na harmonogram lub wyzwalacz, przerwane wykonanie wymaga sprawdzenia modułu błędu, a poprawnie zakończony przebieg bez zmiany w aplikacji może oznaczać filtr lub zapis do innego rekordu.

Moduł wyszukiwania może zwrócić zero wyników bez błędu, jeśli nie ma nowego rekordu albo filtr jest zbyt restrykcyjny. Sprawdź, czy zdarzenie testowe spełnia wszystkie warunki scenariusza.

Scenariusz nie ruszy automatycznie, jeśli harmonogram jest wyłączony lub ustawiony na uruchomienie na żądanie. W edytorze scenariusza sprawdź przełącznik harmonogramu, ustawienia Schedule, strefę czasową oraz daty rozpoczęcia i zakończenia. Oficjalny opis ustawień znajduje się w dokumentacji Scenario settings Make.

Dla wyzwalacza pollingowego zmień testowo rekord spełniający warunki wyszukiwania i uruchom Run once. Dla webhooka wyślij kontrolne zdarzenie, a następnie sprawdź historię i kolejkę. Make podaje, że webhook może zwrócić HTTP 400 z komunikatem `Queue is full`, gdy kolejka jest pełna, oraz HTTP 429 z komunikatem `Too many requests`, gdy zadziała limit żądań. Szczegóły zawiera oficjalna dokumentacja webhooków Make.

Rozróżnij odebranie żądania od wykonania scenariusza. Jeżeli webhook trafia do kolejki, sprawdź częstotliwość przetwarzania i limit kolejki zależny od planu. Zmieniaj jedno ustawienie naraz, aby wynik testu pokazał, która zmiana rozwiązała problem.

Historia wykonania pokazuje, który moduł przerwał przepływ i jakie dane otrzymał. Otwórz historię scenariusza, wybierz nieudany przebieg i kliknij pierwszy moduł oznaczony błędem. Zanotuj nazwę modułu, treść błędu, czas oraz identyfikator rekordu; usuń tokeny i zbędne dane osobowe przed zgłoszeniem.

W ustawieniach scenariusza możesz włączyć przechowywanie niepełnych wykonań. Wtedy Make zapisuje przerwany przebieg do zakładki Incomplete executions, o ile dostępne miejsce nie jest zapełnione. Gdy włączone jest Keep data confidential, log nie przechowuje przetwarzanych danych, więc diagnostyka na podstawie payloadu będzie ograniczona. Zasady opisuje pomoc Make dotycząca niepełnych wykonań.

Dane najczęściej zatrzymuje pusta wartość, niezgodny format albo filtr odrzucający pakiet. W historii wykonania przechodź moduł po module: sprawdź, czy pole występuje w wyjściu poprzednika i czy właściwe pole wybrałeś w mapowaniu.

Sprawdź różnice typów: tekst zamiast daty, liczba z nieoczekiwanym separatorem dziesiętnym, tablica zamiast pojedynczej wartości lub puste pole źródłowe. Po zmianie struktury danych w aplikacji odśwież ustawienia modułu i sprawdź, czy Make rozpoznaje aktualne pola. Przy routerze zweryfikuj warunki każdej ścieżki.

Testuj pojedynczy kontrolowany rekord, który powinien przejść przez filtr. Zapisz jego identyfikator i potwierdź, że moduł docelowy zmienił właśnie ten rekord. Jeśli scenariusz przetwarza wiele elementów, ogranicz pobieraną porcję, aby szybciej znaleźć pierwszy element o nieprawidłowym formacie.

Błąd autoryzacji oznacza, że Make nie może wykonać operacji przy użyciu bieżącego połączenia. W ustawieniach modułu sprawdź nazwę connection, konto właściciela, dostęp do wymaganej aplikacji i uprawnienia do zapisu. Zmiana hasła lub odebranie dostępu może unieważnić autoryzację.

Ponownie połącz aplikację przez edycję connection w module albo sekcję Connections, używając konta z wymaganym dostępem. Nie wklejaj tokenu do zwykłego pola tekstowego ani do zgłoszenia. Po autoryzacji uruchom jeden testowy przebieg przed wznowieniem całej kolejki.

Jeżeli jedno połączenie działa, a drugie nie, upewnij się, że moduły korzystają z właściwego connection i zakresu uprawnień. Dostęp do konta nie zawsze oznacza dostęp do konkretnego pliku, rekordu lub operacji zapisu.

Błąd chwilowy można ponowić po sprawdzeniu skutku operacji, a błąd danych wymaga poprawy przed ponowieniem. Make wskazuje `RateLimitError` i `ConnectionError` jako częste błędy przejściowe; ograniczenie tempa, mniejsza porcja danych i operacje zbiorcze mogą zmniejszyć liczbę przekroczeń limitu.

W Scenario settings opcja Store incomplete executions zapisuje nieudane przebiegi do późniejszej obsługi. Opcja Process data in order wstrzymuje kolejne wykonania do czasu rozwiązania niepełnych przebiegów, co porządkuje kolejność, ale może zwiększyć opóźnienie. Sprawdź też limit miejsca na zapisane wykonania. Make opisuje ustawienia w dokumentacji scenariuszy.

Ponowienie może utworzyć duplikat, jeśli aplikacja docelowa wykonała zapis, ale Make nie dostał potwierdzenia. Przed Retry wyszukaj rekord po identyfikatorze zamówienia lub zdarzenia.

Naprawiaj scenariusz na kopii albo na ograniczonym przebiegu, a zmianę testuj pojedynczym rekordem. Najpierw zachowaj identyfikator wykonania, komunikat błędu i aktualną konfigurację; nie ponawiaj w ciemno operacji tworzącej rekord lub dokument.

1. Zapisz punkt wyjścia. Zanotuj identyfikator wykonania, moduł błędu, czas i konfigurację. Przy większej zmianie skopiuj scenariusz lub zapisz jego blueprint.
2. Sprawdź skutek operacji. W aplikacji docelowej wyszukaj rekord po stabilnym identyfikatorze zamówienia lub zdarzenia.
3. Popraw jedną przyczynę. Zmień mapowanie, filtr, połączenie lub porcję danych, nie kilka niezależnych elementów naraz.
4. Uruchom próbę. Potwierdź zapis w systemie docelowym i sprawdź, czy nie powstał duplikat.
5. Rozwiąż niepełne wykonanie. Ponów tylko te przebiegi, których skutki i bezpieczeństwo ponowienia zostały sprawdzone.
6. Wznów proces i monitoruj kolejkę. Upewnij się, że nowe rekordy przechodzą, a wcześniejsze nie zostały pominięte.

Make opisuje ręczne rozwiązywanie i ponawianie wykonania w instrukcji obsługi niepełnych wykonań. Retry sprawdza się przy przejściowym błędzie połączenia, ale błąd danych zwykle wymaga zmiany mapowania albo konfiguracji.

Jeśli automatyzacja obejmuje kilka systemów i procesów biznesowych, automatyzacja procesów biznesowych pomoże uporządkować przepływ i odpowiedzialność za dane. Gdy scenariusz wymaga poprawy, tester automatyzacji pomoże wskazać procesy i miejsca do diagnozy.

Alert powinien wskazywać nazwę scenariusza, moduł, czas, identyfikator rekordu i rodzaj błędu. Wrażliwy payload oraz tokeny zostaw poza powiadomieniem. Tam, gdzie błąd nie może pominąć zamówienia ani aktualizacji, skonfiguruj ścieżkę obsługi błędu i określ, kto reaguje.

Włącz Store incomplete executions dla procesów, które trzeba wznowić po awarii. Retry error handler może przechować nieudany pakiet i pozostałą część przepływu do automatycznego lub ręcznego ponowienia. Make wymaga włączenia przechowywania niepełnych wykonań dla tego handlera; ustawienia opisuje oficjalna instrukcja Retry error handler.

Perspektywa KC Mobile: scenariusz wymaga kontroli sytuacji, w której system nie wie, czy zapis się udał. Po timeoutcie automatyczne ponowienie może powielić fakturę albo rekord, dlatego przy operacjach tworzących dane warto przed zapisem wyszukać istniejący rekord po unikalnym identyfikatorze zdarzenia.

Przy automatyzacji marketingu podobne reguły dotyczą wysyłki wiadomości i aktualizacji kontaktów. Zobacz materiały o automatyzacji agencji marketingowej w Make, Zapier i n8n, kampaniach SMS i e-mail oraz obsłudze maili w Gmailu i Outlooku.

• Automatyzacje w Make: jak połączyć aplikacje i ograniczyć ręczną pracę
• Wdrożenie automatyzacji w firmie: od procesu do stabilnego działania
• Jakie dokumenty przygotować przed wdrożeniem automatyzacji w firmie?
• Jak automatyzować procesy sprzedaży na marketplace bez chaosu w zamówieniach