Activepieces: автоматизация из триггеров и действий строится так: вы выбираете входное событие, добавляете шаги, подключаете аккаунты и проверяете результат в истории запусков. Документация проекта описывает поток как триггер и выбранные вами шаги, а агент умеет вызывать поток, поток умеет запускать агента, и оба читают одни таблицы.
Входное событие и желаемая запись
Начните с одной фразы: что приходит и что должно появиться на выходе. В учебном примере приходит строка формы с полями id, email и topic, а появиться должен один тикет в таблице. Возьмите условные данные: A — id 105, email a@example.com, topic «Доставка»; B — id 106, пустой email, topic «Цена»; C — повтор записи A. Ожидаемая таблица: ticket_id берётся из id, contact из email, category из topic после классификации, source_id из id. Так вы фиксируете контракт до сборки: какие поля обязательны, какое поле служит ключом повтора, что делать с пустым email. Формулировка «создать тикет» слишком широка. Запись создать одну строку с ticket_id 105 и source_id 105; при пустом email остановить запись проверяема. Документация проекта перечисляет строительные блоки: агенты, потоки, таблицы и приложения. Поток — это триггер и выбранные вами шаги. Таблица хранит данные в строках и столбцах, и её читают и поток, и агент. Приложения дают агенту инструменты для задач. На главной странице проекта указано 770+ приложений и 760+ приложений в документации; это разные срезы одного каталога. Для входа выберите событие, которое несёт все нужные поля сразу: вебхук формы, новая строка таблицы, новое письмо. Если событие приносит только ссылку, добавьте шаг получения записи и проверьте, что он вернул.
Проверка trigger и action внутри коннектора
Наличие бренда в каталоге подтверждает существование коннектора. Нужную операцию проверяют внутри него. Откройте коннектор и посмотрите список триггеров и действий: есть ли триггер «новая строка», есть ли действие «создать запись», какие поля оно требует. Документация проекта называет приложения инструментами агента и основой потоков. Прайс-страница проекта уточняет: при отсутствии готовой интеграции работает HTTP-шаг или вебхук для всего, у чего есть API, а части кода открыты на TypeScript, поэтому интеграцию можно собрать. Практический порядок: выпишите требуемое действие словами, откройте коннектор, найдите операцию с подходящим названием, прочитайте её входные поля, сверьте с вашим контрактом. Если операция создаёт запись и возвращает идентификатор, она годится для проверки повтора. Если операция только ищет, добавьте отдельное действие записи. Соберите таблицу соответствия: поле события, поле действия, обязательность, источник значения. Пустое поле в этой таблице означает пропущенный шаг сборки. Проверка внутри коннектора занимает минуты и снимает целый класс ошибок, когда поток собран, а нужной операции у коннектора нет.
| Что проверяем | Где смотрим | Признак готовности |
|---|---|---|
| Триггер события | Список триггеров коннектора | Событие несёт id, email, topic |
| Действие записи | Список действий коннектора | Операция создаёт строку и возвращает id |
| Поля действия | Форма настройки шага | Обязательные поля совпали с контрактом |
| Запасной путь | HTTP-шаг или вебхук | Есть API у вашего сервиса |
Тестовые аккаунты и поля шага
Подключите тестовый аккаунт назначения и тестовый источник. Документация проекта описывает подключение приложения один раз: после этого его видят потоки, агенты и коллеги. На главной странице проекта сказано, что учётные данные могут оставаться в вашем хранилище секретов, а ключи AI-провайдеров можно приносить свои. Для проверки это означает: тестовый аккаунт отделён от рабочего, и запись уйдёт в тестовую таблицу. После подключения откройте шаг и посмотрите, какие поля он показывает. Поля появляются из схемы действия и из данных предыдущего шага. Свяжите их явно: ticket_id из id, contact из email, category из topic. Там, где значение приходит из события, подставляйте ссылку на поле события. Константа в поле email даст подстановку чужого адреса при втором входе. Проверьте типы: строка, число, дата. Если действие ждёт число, а событие приносит строку, добавьте преобразование. Отдельно проверьте необязательные поля: пустой topic при жёсткой валидации остановит шаг, при мягкой пройдёт дальше. Решение о поведении при пустом поле примите здесь, на форме шага, и зафиксируйте в контракте.
Жёсткая валидация и AI-классификация
Разведите две задачи. Жёсткая валидация проверяет перенос идентификаторов: id и email попадают в запись без изменений. AI-классификация предлагает категорию по тексту topic. В учебном примере category выводится из topic после ручного или AI-разбора, а id и email переносятся без выдумки. Практический порядок: сначала шаг проверки обязательных полей, затем шаг классификации, затем шаг записи. Если email пуст, поток останавливается и возвращает missing_email. Классификация на этом входе не запускается. Если email заполнен, классификация предлагает категорию, а запись сохраняет и её, и исходные id с email. Прайс-страница проекта поясняет экономику AI-шагов: запуск стоит один кредит независимо от числа шагов, а AI-шаг считается отдельно, потому что провайдеру платит платформа; быстрая модель — 2 кредита, умная — 10, фронтирная — 20, агентные действия — по 1 кредиту. Свои ключи AI-провайдера на платных тарифах снижают AI-шаг до 1 кредита и переносят стоимость модели в счёт провайдера. Отсюда правило сборки: классифицируйте только те входы, которые прошли валидацию. Так вы не платите за разбор заведомо неполных записей.
Нормальный, неполный и повторный вход
Прогоните три входа по очереди. Нормальный: A с id 105 создаёт один тикет 105, после чтения записи обратно вы видите ticket_id 105. Неполный: B с id 106 и пустым email останавливает запись и возвращает missing_email. Повторный: C, повтор A, не создаёт второй тикет 105 после проверки source_id. Проверка source_id — собранное правило вашего примера. Оно предотвращает повторную запись в этом потоке и не означает, что продукт обеспечивает ровно одну запись для любого коннектора. Стройте проверку так: перед созданием ищите запись по source_id, при находке завершайте поток без записи. Матрица проверки:
| Вход | Условие | Ожидание | Итог |
|---|---|---|---|
| A | id 105, email заполнен | Создан один тикет 105 | PASS после чтения записи |
| B | id 106, email пуст | Запись остановлена, возврат missing_email | FAIL, если email подставлен из A |
| C | повтор A | Второй тикет 105 отсутствует | FAIL, если создан второй тикет |
Здесь FAIL обозначает провал учебной проверки. Если на входе B в запись попал email из A, значит поле связано константой. Если на входе C появился второй тикет, значит проверка source_id не выполняется или выполняется после записи.
Draft, тестовый запуск и публикация
Держите четыре отдельных статуса: сохранённый черновик, тестовый запуск, опубликованная версия, наличие записи в назначении. На главной странице проекта рядом с примером потока показаны переключатели Live и Test. Черновик хранит вашу сборку. Тестовый запуск выполняет шаги на выбранных данных. Публикация включает поток для реальных событий. Запись в назначении подтверждается чтением таблицы. Эти статусы независимы: публикация потока без проверки истории не означает доставку. Практический порядок перехода: соберите черновик, прогоните тестовые входы, проверьте историю, прочитайте запись в назначении, затем публикуйте. Если после публикации меняете шаг, вернитесь к тестовому запуску. Публикация без прогона трёх входов оставляет непроверенными неполный и повторный сценарии.
История запусков и реальная запись
Откройте историю запусков и разберите один запуск по шагам. Смотрите вход и выход каждого шага: что пришло в триггер, что вернула проверка, что ушло в действие записи. Затем откройте таблицу назначения и найдите строку по ticket_id. Совпадение выхода шага и строки в таблице — доказательство доставки. Главная страница проекта описывает возобновление запусков с последней контрольной точки, поэтому в истории видно, с какого шага продолжился прерванный запуск. Если шаг записи вернул идентификатор, а строки в таблице нет, проверьте, в тот ли проект и аккаунт пишет шаг. Если строка есть, а идентификатор пуст, проверьте связь поля. Для повторного входа ищите в истории запуск C и убедитесь, что шаг записи пропущен по проверке source_id. Держите в истории короткую метку входа, чтобы отличать A, B и C при разборе.
Cloud, своя установка и редакции
Документация проекта предлагает два старта: облако без настройки и обслуживания либо своя установка одной командой. Прайс-страница проекта перечисляет варианты размещения: облако или собственные серверы, включая полностью изолированный контур без исходящей сети. Там же сказано, что своя установка определяет место запуска, а Community Edition содержит ядро автоматизации; платные уровни добавляют управление доступом, разделение команд и клиентов, безопасную доставку изменений, агентов и чат. Своя установка сохраняет расходы на AI и API и работу по обслуживанию. Прайс-страница проекта приводит цены: Free за $0, Plus за $20 в месяц, Team за $200 в месяц, Ultimate по договорённости, Embed от $36k в год. Квоты и ритм обновления кредитов на странице тарифов расходятся между разделами, поэтому точный ритм сверяйте на актуальной странице перед выбором. Критерий выбора: нужны ли вам SSO, роли, журнал аудита, свои хранилища секретов и агенты. Эти возможности перечислены в платных уровнях. Ответственность за обслуживание своей установки лежит на вашей команде.
Частые вопросы
Что такое Activepieces простыми словами?
Это платформа автоматизации, где поток собирается из триггера и выбранных шагов. Документация проекта перечисляет блоки: агенты, потоки, таблицы и приложения. Агент умеет вызывать поток, поток умеет запускать агента, оба читают одни таблицы.
Чем cloud отличается от self hosted?
Облако работает без настройки и обслуживания с вашей стороны. Своя установка запускается одной командой на вашей инфраструктуре, включая изолированный контур. Прайс-страница проекта относит к платным уровням управление доступом, роли, журнал аудита и свои хранилища секретов.
Сколько стоит и что с кредитами?
Free стоит $0, Plus — $20 в месяц, Team — $200 в месяц, Ultimate — по договорённости. Запуск стоит один кредит независимо от числа шагов, AI-шаг считается отдельно: быстрая модель 2 кредита, умная 10, фронтирная 20. Свои ключи AI-провайдера на платных тарифах снижают AI-шаг до 1 кредита.
Можно ли подключить сервис без готовой интеграции?
Да. Прайс-страница проекта указывает HTTP-шаг и вебхук для всего, у чего есть API. Части кода открыты на TypeScript, поэтому интеграцию можно собрать. Наличие бренда в каталоге подтверждает коннектор, а нужную операцию проверяйте внутри него.
Как убедиться, что запись действительно создана?
Откройте историю запусков и посмотрите вход и выход каждого шага. Затем найдите строку в таблице назначения по ticket_id. Совпадение выхода шага и строки подтверждает доставку. Публикация потока сама по себе доставку не подтверждает.
Задача: собрать поток обработки строки формы в Activepieces.
Триггер: новое событие формы с полями id, email, topic.
Шаг 1. Проверка: если email пуст — остановить поток и вернуть missing_email.
Шаг 2. Классификация: по тексту topic предложить category.
Шаг 3. Поиск: найти запись по source_id, равному id.
Шаг 4. Если запись найдена — завершить поток без создания.
Шаг 5. Создание: ticket_id = id, contact = email, category = результат шага 2, source_id = id.
Шаг 6. Чтение: получить созданную запись по ticket_id и сверить поля.
Проверочные входы:
A: id 105, email a@example.com, topic "Доставка" — ожидается один тикет 105.
B: id 106, email пуст, topic "Цена" — ожидается остановка и missing_email.
C: повтор A — ожидается отсутствие второго тикета 105.
Под себя замените: [название формы], [поля события], [таблицу назначения], [правило категорий].