Activepieces — платформа автоматизации с открытым исходным кодом, где бизнес-операцию собирают как flow: один триггер и цепочка шагов на готовых приложениях. Для заявки с сайта, письма в общий ящик или строки в таблице этого хватает, пока у операции есть владелец, понятный результат и журнал запусков. Если ошибка шага ведёт к юридически значимой записи, рядом с платформой нужен контроль на стороне вашего сервера.
Что за платформа
Activepieces собирает автоматизацию из flow: триггер запускает цепочку шагов, а каталог готовых приложений даёт соединения с почтой, таблицами, мессенджерами и CRM. Платформу разворачивают на своём сервере или берут в облаке.
По документации Activepieces, основные сущности платформы — агенты, flows, таблицы и приложения. Для операции с известными шагами хватает flow. Агент нужен там, где путь определяется по ходу работы, а у заявки путь известен заранее: принять, проверить, записать, сообщить. Поэтому первую автоматизацию собирают из flow, а шаг с ИИ добавляют в точке, где нужен текст: краткое резюме обращения, черновик ответа, выбор темы из заранее заданного списка.
Сравнение платформ разобрано в статье n8n или Make; Activepieces претендует на тот же класс задач и выбирается по трём вопросам: где будут жить данные, кто сопровождает сценарии и какие интеграции нужны в первый день. Каталог приложений проверьте по списку ваших систем: общее число в рекламе второстепенно, а отсутствие нужной интеграции означает вызов по API или собственный шаг, то есть работу разработчика.
Условия лицензии читайте на странице License в документации и в репозитории проекта. Часть возможностей относится к корпоративным: в описании платформы упоминаются SSO, SCIM и журналы аудита. Перед запуском определите, какие функции нужны вам, и на каких условиях они доступны для вашего способа развёртывания.
Триггер и поля
Возьмите одну операцию с коротким путём. Типовой вариант: заявка с формы сайта попадает в таблицу, дубль ищется по телефону или почте, ответственному менеджеру уходит сообщение. Прежде чем открывать редактор, запишите контракт операции: какие поля приходят на вход, какие записываются на выходе и кто отвечает за результат. Без такого описания flow превращается в набор шагов, которые каждый понимает по-своему.
Выбор триггера влияет на скорость и надёжность. Вызов от формы приходит сразу, но если платформа в этот момент недоступна, событие теряется, и форме нужна запасная запись в таблицу. Наблюдение за таблицей работает с задержкой опроса, зато каждая строка остаётся на месте и ждёт обработки. Для заявок, которые нельзя потерять, надёжнее второй вариант или оба сразу.
- Выберите триггер: приём вызова от формы по адресу, который выдаёт платформа, либо наблюдение за новой строкой таблицы. Приём от формы даёт мгновенный запуск, наблюдение за таблицей запускается с задержкой опроса.
- Сохраните тестовое событие и сверьте имена полей. Расхождение «телефон» и «phone» ломает следующие шаги, поэтому имена фиксируют в первом тесте.
- Добавьте шаг очистки: приведите телефон к одному формату, удалите пробелы из почты, обрежьте комментарий до разумной длины.
- Добавьте поиск дубля в таблице клиентов. Результат поиска определяет ветку: найден — дописать обращение к существующей записи, пусто — создать новую.
- Завершите flow уведомлением ответственному, где есть ссылка на запись, а полные данные остаются в системе.
Поля с персональными данными передавайте только туда, где они нужны для задачи. Если уведомление уходит в общий чат, достаточно имени, темы и ссылки на запись. Остальное менеджер увидит в системе с разграничением прав, как описано в материале про права, секреты и проверку ИИ-агентов.
Секреты и доступ
Каждое приложение в flow подключается через connection: ключ, токен или авторизация от имени сервисной учётной записи. Заведите для автоматизации отдельную учётную запись с минимальными правами в CRM и таблицах. Тогда в журнале видно, что запись сделал робот, а при увольнении сотрудника сценарии продолжают работать. Подключение на личный аккаунт руководителя оставляет компанию с автоматизацией, которая замолчит вместе с его паролем.
Ключи храните в подключениях платформы и ни в одном текстовом поле шага. Проверьте, кто в вашей команде видит список подключений и может ли он их менять: права на редактирование flow и права на управление секретами разделяют по ролям. Для тестового и рабочего контуров заведите разные подключения, чтобы отладка писала только в тестовую таблицу.
При самостоятельной установке добавляется ответственность за сервер: обновления, резервная копия базы платформы, доступ извне и защита панели управления. В облачном варианте эта часть лежит на вендоре, а вам остаётся решить, готовы ли вы передавать ему данные операции. Развёртывание на своём сервере подробно сравнивается в разборе облака и своего сервера для n8n, и логика выбора там та же.
Какую одну операцию в вашей компании стоит автоматизировать первой?
Сбой и повтор
Шаг падает по разным причинам, и реакция зависит от причины. Временная недоступность чужого сервиса лечится повтором с паузой. Неверный формат данных после повтора остаётся неверным и требует отправки заявки на ручной разбор. Наличие автоматического повтора и его параметры сверьте в документации выбранной версии, а в тесте подтвердите на живом сбое: отключите подключение и посмотрите, что произойдёт с запуском.
| Ситуация | Что видно в запуске | Действие команды |
|---|---|---|
| Сервис временно недоступен | Шаг завершился ошибкой соединения | Повторить с паузой, ограничить число попыток |
| Истёк или отозван ключ | Ошибка авторизации на шаге | Обновить подключение, повторить запуск вручную |
| Пришли пустые поля | Следующий шаг получил пустое значение | Остановить ветку, отправить заявку человеку |
| Повторный запуск создал дубль | Две записи с одним телефоном | Добавить поиск дубля до записи |
Главный риск повтора — двойное действие. Если шаг успел создать запись, а ответ потерялся, повторный запуск создаст вторую. Поэтому операции записи делают идемпотентными: перед созданием ищут существующую запись по ключу, например по номеру заявки. Тот же принцип описан в статье про входящие события, проверку и повтор в n8n.
Отдельно решите, кому уходит сообщение о сбое. Письмо в общий ящик тонет среди прочих, поэтому уведомление об ошибке направляют конкретному владельцу flow и дублируют в рабочий чат с короткой фразой: какой flow упал, на каком шаге и где открыть запуск. Содержимое заявки остаётся в системе.
Приёмка и запуск
Критерий готовности формулируйте через результат, а число построенных шагов вторично. Заявка из формы появилась в таблице один раз, менеджер получил сообщение со ссылкой, а ошибочная заявка попала на ручной разбор вместо исчезновения. Прогоните десять обезличенных тестовых заявок: нормальные, с пустым телефоном, с повтором, с очень длинным комментарием. Сверьте каждую с журналом запусков платформы.
Назначьте владельца flow и назовите человека, который смотрит историю запусков. Автоматизация без владельца ломается тихо: ключ истекает, форма на сайте меняет поля, а заявки продолжают приходить в никуда. Раз в неделю владелец открывает список неудачных запусков и разбирает каждый. Когда ИИ-шаг пишет текст клиенту, отправку подтверждает сотрудник, потому что права и подтверждения проверяет сервер, а модель предлагает формулировку.
Через месяц после запуска пересмотрите flow по журналу: какие ветки за месяц остались без запусков, где чаще всего возникает ручной разбор, какие шаги тратят больше всего времени. Лишние ветки убирают, частые причины ошибок закрывают проверкой на входе. Так сценарий остаётся понятным тому, кто откроет его через полгода.
Выберите заявку с одной формы и напишите на листе пять полей, которые она должна нести. Соберите flow из трёх шагов: триггер, поиск дубля, запись. Уведомление и ИИ-шаг добавляйте после того, как десять тестов проходят подряд. Если сборку лучше передать нам, начните с раздела про автоматизацию бизнес-процессов и опишите операцию, с которой стартуете.