7 ошибок в Make.com-сценариях, которые потом съедают часы на ручные правки

7 ошибок в Make.com-сценариях, которые потом съедают часы на ручные правки

Чаще всего Make ломается не на «сложной логике», а на мелочах: сценарий работает в тесте, а в бою плодит дубли, пропускает записи и упирается в лимиты. Если это не поймать на старте, вместо автоматизации получаешь новую рутину.

• Не ставят фильтр сразу после триггера — и дальше идут лишние модули, которые можно было не запускать.
• Не нормализуют данные в одном месте: в одном узле дата строкой, в другом массивом, и на выходе хаос.
• Не делают idempotency: нет проверки по ID, значит повторный запуск создаёт дубликаты.

Сценарий: вход из webhook → фильтр → поиск записи → ветка update/create → уведомление в Telegram. Это базовая схема для CRM, трекинга лидов и загрузки креативов. Узкое место здесь — повторные триггеры и пустые поля: лечится обязательной проверкой существования записи до записи в базу.

Ещё одна типовая ошибка — не считать ошибки по модулям. Если внешний API вернул лимит или таймаут, сценарий должен не падать молча, а уходить в отдельную ветку с логом и retry. Иначе отладка превращается в раскопки по execution history.

Держи правило: сначала фильтр и нормализация, потом запись, потом уведомление. Тогда Make остаётся конвейером, а не генератором сюрпризов.