Щоб налаштувати повторні спроби в Make, увімкніть Store incomplete executions у налаштуваннях сценарію. За потреби додайте конкретному модулю обробник через Add error handler. Повторюйте передусім тимчасові збої, а для помилок даних чи авторизації спочатку усуньте причину. Перед повтором перевірте результат у зовнішньому сервісі: запит міг виконатися, навіть якщо Make не дочекався відповіді.
Що перевірити перед налаштуванням
Інструкція спирається на онлайн-довідку Make, перевірену 7 листопада 2026 року. Документація не прив’язана до зафіксованої версії продукту, тому назви в інтерфейсі можуть відрізнятися. Зокрема, обробник пропуску пакета в матеріалах Make трапляється як Skip або Ignore.
Для роботи потрібні доступ до редактора сценарію, дані про помилку та безпечні тестові записи. Якщо ви ще не орієнтуєтеся в модулях і з’єднаннях, почніть зі створення першого сценарію Make.
- Знайдіть проблемний модуль. Перевірте назву помилки, вхідні дані та повідомлення сервісу, а не лише статус запуску.
- Визначте критичність запису. Необов’язковий опис і важливу заявку не можна обробляти за однаковим правилом пропуску.
- Перевірте доступне сховище. Незавершені виконання займають місце в межах лімітів плану.
- Перевірте доступ до зовнішнього сервісу. Його історія або дані потрібні, щоб з’ясувати, чи виконався запит.
- Підготуйте безпечний тест. Він не повинен надсилати справжні повідомлення клієнтам або змінювати незамінні дані.
Як визначити, чи допоможе повтор
Обробник помилки задає реакцію на збій конкретного модуля. Незавершене виконання, або incomplete execution, — це збережене невдале виконання, яке можна повторити або виправити вручну. Це різні механізми: обробник визначає поведінку, а збережене виконання дає можливість повернутися до проблемного місця.
У Make дані передаються пакетами — bundles. Пакетом може бути окрема заявка, контакт чи рядок таблиці. Тому пропуск помилкового пакета означає, що цей запис не пройде наступні кроки.
| Помилка | Що перевірити | Доречна дія |
|---|---|---|
| RateLimitError | Ліміти API та частоту запитів; Make пов’язує помилку з HTTP 429. | Дочекатися відновлення квоти; якщо помилка повертається, зменшити навантаження. |
| ConnectionError | Доступність стороннього застосунку; пов’язані статуси — HTTP 502, 503, 504. | Повторити після тимчасового збою, перевіривши результат попереднього запиту. |
| ModuleTimeoutError | Чи не виконалася операція у сторонньому сервісі, хоча Make не отримав відповіді вчасно. | Спочатку перевірити ризик дублювання, потім вирішувати питання повтору. |
| BundleValidationError | Обов’язкові поля, типи значень і мапінг — відповідність вхідних даних полям модуля. | Виправити дані або мапінг; повтор без змін зазвичай не допоможе. |
| AccountValidationError | Чинність облікових даних і з’єднання із застосунком. | Перевірити або створити з’єднання заново. Помилка виникає під час ініціалізації сценарію, тому обробник помилки модуля не підходить. |
Практичне правило: якщо причина може зникнути без зміни даних або налаштувань, повтор може допомогти. Якщо проблема в даних, мапінгу чи авторизації, спочатку потрібне виправлення.
Крок 1. Увімкніть збереження незавершених виконань
За замовчуванням збереження незавершених виконань вимкнене.
- Відкрийте сценарій у Scenario Builder.
- Натисніть значок шестерні — Scenario settings.
- Увімкніть Store incomplete executions.
- Перевірте налаштування Discard data if storage is full.
- Збережіть зміни сценарію.
Ризик для даних: якщо сховище переповниться, увімкнене Discard data if storage is full може призвести до безповоротного відкидання даних невдалого виконання. Сам перемикач збереження не гарантує, що всі записи залишаться доступними.
Для критичних записів потрібні контроль сховища та своєчасне розв’язання помилок. Якщо сховище вже переповнене, не намагайтеся підтримати роботу відкиданням важливих даних без узгодженого плану відновлення — зверніться до адміністратора інтеграції.
Окремо перевірте Keep data confidential. Коли це налаштування ввімкнене, Make не зберігає фактичні дані обробки в логах, що суттєво обмежує діагностику й виправлення. Не вимикайте захист лише заради зручнішого журналу, доки не оціните, яка чутлива інформація потрапляє у сценарій.
Крок 2. Виберіть обробник за наслідками
Обирайте обробник залежно від того, чи можна відкинути пакет, підставити запасне значення або зупинити виконання.
| Обробник | Що робить | Коли доречний | Головне обмеження |
|---|---|---|---|
| Retry | Зберігає незавершене виконання для автоматичного чи ручного повтору; інші пакети можуть оброблятися далі. | Тимчасовий збій або відкладене відновлення. | Не виправляє постійну причину помилки. |
| Skip / Ignore | Пропускає пакет із помилкою та продовжує сценарій. | Пакет можна свідомо відкинути. | Успішний статус сценарію не означає, що всі записи оброблено. |
| Resume | Підставляє задане вихідне значення замість результату помилкового модуля. | Є безпечне й осмислене запасне значення. | Підстановка має підходити наступним модулям за змістом і типом. |
| Commit | Зупиняє запуск і фіксує зроблені зміни в модулях із підтримкою транзакцій. | Потрібно зберегти проміжний результат і зупинитися. | Наступні кроки не виконуються; це не відкат. |
| Rollback | Зупиняє запуск і скасовує зміни в модулях із підтримкою транзакцій. | Потрібно скасувати підтримувані транзакційні зміни. | Не скасовує нетранзакційні дії; результат також залежить від Auto-commit. |
Транзакція дозволяє зафіксувати або скасувати підтримувані зміни як єдину операцію. Не кожен модуль Make підтримує таку поведінку.
Ризик для даних: Rollback не скасує вже надісланий лист або видалення файлу нетранзакційним модулем. За ввімкненого Auto-commit попередні зміни можуть бути вже зафіксовані й не відкочуватися. Не використовуйте Rollback як універсальне відновлення, доки не перевірите підтримку транзакцій конкретними модулями.
Resume доречний лише тоді, коли запасне значення не спотворює дані. Наприклад, нейтральний текст для необов’язкового опису може бути прийнятним, а довільна заміна ідентифікатора замовлення — ні. Skip не підходить для незамінних записів без окремого контролю пропусків.
Крок 3. Налаштуйте Retry та розрізняйте режими повтору
- Клацніть правою кнопкою потрібний модуль.
- Виберіть Add error handler → Retry.
- Переконайтеся, що Store incomplete executions увімкнене.
- Виберіть автоматичне завершення виконання або ручне розв’язання.
- Для автоматичного режиму перевірте кількість спроб та інтервал.
- Збережіть сценарій і перевірте поведінку на безпечних даних.
Make описує різні режими в документації автоматичних повторів. Наведені нижче параметри перевірені 7 листопада 2026 року.
- Повтори через Retry handler: типові параметри — максимум 3 спроби з інтервалом 15 хвилин. Їх можна змінювати в налаштуваннях обробника.
- Автоматичні повтори для RateLimitError, ConnectionError і ModuleTimeoutError: за ввімкненого збереження незавершених виконань Retry не обов’язковий. Документація наводить послідовні паузи: 1 хвилина, 10 хвилин, 10 хвилин, 30 хвилин, 30 хвилин, 30 хвилин, 3 години та 3 години.
Це різні механізми: інтервали автоматичного відновлення зазначених типів помилок не слід плутати з налаштовуваними параметрами Retry handler. Жоден розклад не гарантує, що зовнішній сервіс відновиться до наступної спроби.
Для повторів незавершених виконань Make обмежує паралельну обробку 3 виконаннями на сценарій. Якщо запуск сценарію вже триває, повтор чекає його завершення.
Ризик дублювання: перед увімкненням автоматичних повторів для модуля, який створює записи або надсилає повідомлення, перевірте, як контролюватимете повторне виконання зовнішньої дії. Тайм-аут не доводить, що сервіс не прийняв запит.
Для RateLimitError самих повторів може бути недостатньо: якщо сценарій постійно перевищує квоту API, зменште частоту або обсяг запитів. На навантаження впливає і спосіб отримання даних — відмінності пояснено в матеріалі про webhook і періодичну перевірку.
Крок 4. Перевірте й відновіть невдале виконання
- Відкрийте сценарій і перейдіть до Incomplete executions.
- Виберіть потрібний запис та відкрийте Details.
- Перевірте модуль із попередженням, вхідні значення та історію виконання.
- Зіставте результат операції з історією або даними зовнішнього сервісу.
- Для усунутого тимчасового збою використайте Retry selected.
Ризик для даних: повтор починається з проблемного модуля й може продублювати замовлення, повідомлення чи інший запис, якщо зовнішній сервіс уже виконав початковий запит. Якщо результат невідомий, не запускайте повтор навмання.
Якщо потрібно змінити мапінг або конфігурацію, спочатку виправте й збережіть сценарій, а потім переходьте до ручного розв’язання збереженого виконання. Звичайний Retry не слід вважати запуском із новою конфігурацією: Make зазначає, що повтор використовує налаштування початкового збою. Для таких випадків звіряйте процедуру з довідкою керування незавершеними виконаннями.
Після відновлення перевірте не тільки статус Make, а й кінцевий результат: правильний контакт, потрібний рядок, відсутність повторного повідомлення. Для CRM повторні спроби варто поєднувати із захистом від дублювання контактів.
Не спрацювало: причина й наступний крок
| Що не спрацювало | Можлива причина | Наступний крок |
|---|---|---|
| Немає запису для відновлення | Збереження не було ввімкнене або дані відкинуто за переповнення. | Перевірте Store incomplete executions, доступне сховище та Discard data if storage is full. Відкинуті через переповнення дані відновити не можна. |
| Запис є, але автоматичного повтору немає | Тип помилки не підтримує цей режим або Retry залишено для ручного розв’язання. | Звірте тип помилки й налаштування обробника. |
| Повтор не починається в очікуваний момент | Триває запуск сценарію або досягнуто ліміту паралельних повторів. | Перевірте поточні виконання й розклад; не додавайте ручних запусків навмання. |
| Після повтору та сама помилка | Причина постійна або повтор використовує початкові налаштування. | Перевірте дані, мапінг, з’єднання та процедуру ручного виправлення. |
| Сценарій успішний, але запису немає | Skip міг пропустити пакет. | Перевірте маршрут обробки помилки й запровадьте контроль пропущених записів. |
| З’явився дубль | Початковий запит міг виконатися без підтвердження для Make. | Припиніть повтори та звірте записи у сторонньому сервісі. |
Коли зупинити повтори й звернутися по допомогу
Припиніть самостійні повтори й зверніться до адміністратора інтеграції або підтримки сервісу, якщо:
- авторизація знову порушується після перевірки з’єднання;
- виникають незрозумілі дублікати чи пропуски важливих записів;
- сховище переповнене, а незавершені виконання містять критичні дані;
- невідомо, чи завершилася фінансова або інша незворотна зовнішня дія;
- помилка стороннього API не зникає після виправлення очевидних налаштувань.
Це практичні ознаки для ескалації, а не офіційні пороги Make. Продовження повторів за невідомого результату може створити додаткові дублікати або ускладнити відновлення даних.
Рекомендація: увімкніть збереження незавершених виконань, визначте причину збою й лише потім обирайте обробник. Для підтримуваних тимчасових помилок окремий Retry може бути зайвим; для помилок даних і доступу потрібне виправлення причини. Skip і Resume застосовуйте лише за допустимих наслідків для запису, а Commit і Rollback — після перевірки транзакцій. Результат завжди перевіряйте і в Make, і в зовнішньому сервісі.
Оновлено 07.11.2026
