Перейти к содержанию

Типы узлов

Start Event

Точка входа в процесс. Определяет откуда приходят данные и как запускается процесс.

Типы триггеров

API — процесс запускается через JSON-RPC (process.start). Входные данные передаются в параметре variables. Вы описываете ожидаемые поля через редактор выходных данных или кнопку «Импорт из JSON».

Webhook — аналогично API, но вызывается внешним сервисом по callback-URL.

Telegram — процесс запускается автоматически при сообщении в Telegram-боте. Системные данные доступны автоматически: message_text, external_username, external_user_id, channel.

Wazzup — процесс запускается при сообщении через агрегатор Wazzup. Поддерживает WhatsApp, Instagram и Viber через один аккаунт. Помимо стандартных системных полей доступны дополнительные: chat_type (тип мессенджера — whatsapp/instagram/viber), contact_phone (телефон клиента), channel_id_wazzup (ID канала в Wazzup).

MAX — аналогично Telegram, для мессенджера MAX.

Web-чат — процесс запускается при сообщении из внешнего веб-чата. Используется для интеграции с вашим сайтом или внешней системой. Внешняя система отправляет сообщения через API, а ответы получает на настроенный webhook URL. Подробнее: Интеграции — Web-чат и внешние системы.

Таймер — процесс запускается по расписанию (cron). Простой режим: «каждые N часов/дней в HH:MM». Продвинутый: cron-выражение. После таймерного старта нет клиента и диалога — AI Chat после таймера недоступен.

Импорт полей из JSON

Для API и Webhook — кнопка «Импорт из JSON». Вставьте пример JSON-запроса, и Schemix автоматически создаст поля с правильными типами:

{"order_id": 123, "amount": 500, "customer": "Иван"}
→ создаст поля: order_id (число), amount (число), customer (строка).

End Event

Завершает процесс. Когда токен достигает End Event, экземпляр переходит в статус Completed.

Выходные данные процесса

В настройках End Event можно выбрать, какие переменные вернуть в ответе API (process.status). Отметьте чекбоксами нужные поля. Если ничего не выбрано — возвращаются все переменные.

Это полезно чтобы не отдавать промежуточные данные (status_code каждого Service Task) вызывающей стороне.

AI Task

Одноразовый вызов LLM для обработки данных. AI Task получает переменные из предыдущих узлов, отправляет промпт в LLM и возвращает структурированный результат.

Настройки

System Prompt — инструкция для AI. Описывает роль и формат ответа. Поддерживает подстановку переменных через кнопку { } Переменная.

User Prompt — сообщение от пользователя / данные для обработки. Обычно содержит переменные из предыдущих узлов.

Task Class — сложность задачи (Light / Medium / Heavy). Определяет какую модель использовать.

Max Tokens — максимальная длина ответа AI.

База знаний (RAG) — опционально. Если выбрана — AI получает релевантные фрагменты из базы знаний как дополнительный контекст.

Выходные данные — поля, которые AI вернёт в JSON-ответе. Например: category (строка), urgency (строка). Эти поля становятся доступны следующим узлам.

AI Chat

Многоходовый диалог с клиентом через AI. AI Chat ведёт разговор, опираясь на базу знаний, и автоматически определяет когда передать кейс оператору.

Настройки

Приветствие — первое сообщение клиенту при входе в диалог.

System Prompt — инструкция для AI: как общаться, на какие темы отвечать, когда эскалировать.

База знаний — выберите базу знаний для RAG-поиска. AI будет отвечать на основе загруженных документов.

Max раундов — максимальное количество обменов сообщениями. После достижения лимита — автоматическая эскалация.

Таймаут неактивности — если клиент не отвечает N секунд — процесс продолжается (с exit_type = timeout).

Условия выхода

AI Chat завершается по одному из условий:

  • Эскалация — AI определил, что клиент просит оператора (через LLM intent)
  • Решено — AI вернул {"action": "resolve"}
  • Таймаут — клиент не отвечает
  • Max раундов — лимит диалога достигнут

Выходная переменная exit_type (escalate / resolved / timeout / max_rounds) доступна для условий в Gateway.

STT Task

Транскрибация аудиозаписи в текст. Используется перед AI Task / AI Chat или как самостоятельный узел анализа звонков.

Настройки

Провайдер — YandexSpeechKit (русская речь, диаризация) или Whisper (мультиязык). Настраивается централизованно в разделе AI-провайдеры.

Источник аудио — переменная предыдущего узла (например, audio_url из Webhook) или прикреплённый файл.

Диаризация — определение кто говорит (спикер 1, спикер 2). Полезно для записей звонков с клиентом и оператором.

Суммаризация — автоматическое краткое содержание через AI.

Выходные данные

  • transcript (строка) — полный текст
  • segments (массив) — реплики с таймкодами и спикерами (если диаризация)
  • summary (строка) — краткое содержание (если включена суммаризация)

Подробнее: STT — Транскрибация.

User Task

Задача для оператора. Создаётся в inbox, оператор заполняет форму и принимает решение.

Настройки

Назначение — кому отправить задачу:

  • Конкретные пользователи (мультиселект с чекбоксами)
  • Всем (если никто не выбран) — задача видна всем операторам, кто первый взял

Поля формы — что оператор заполняет. Типы: текст, число, textarea, select. Каждое поле автоматически становится выходной переменной.

SLA — время на выполнение (минуты). При нарушении: уведомление менеджера, переназначение или пометка «просрочена».

Service Task

Вызов внешнего сервиса или отправка сообщения клиенту.

Тип: HTTP

HTTP-вызов к внешнему API.

Метод — GET, POST, PUT, PATCH, DELETE.

Endpoint — URL внешнего API. Поддерживает переменные: https://api.example.com/orders/{{ variables.order_id }}.

Заголовки — key-value editor. Кнопка 🔒 шифрует значение (API-ключи, токены).

Тело запроса — конструктор полей:

  • «+ Переменная» — выбрать из dropdown доступных переменных предыдущих узлов
  • «+ Статическое поле» — ввести фиксированное значение
  • «Расширенный режим» — свободный Jinja-шаблон

Выходные данные — поля, которые ожидаем в JSON-ответе API. Автоматически добавляются системные: status_code (число) и success (true/false). Пользовательские поля извлекаются из JSON body ответа. Если поля нет в ответе — значение null.

Timeout — максимальное время ожидания ответа (секунды).

Поведение при HTTP-ошибке. При не-2xx ответе (например 500) выходные данные всё равно извлекаются: status_code=500, success=false, плюс поля из тела ответа (если оно валидный JSON). Token идёт дальше, task COMPLETED. Если нужна compensation-ветка по статус-коду — добавь Exclusive Gateway после Service Task с условием на success или status_code.

Только при сетевой ошибке (timeout, DNS, connection refused) task FAILED, выходные данные не извлекаются, в variables попадает error="...".

Тип: Мессенджер (текущий диалог)

Отправка сообщения клиенту в рамках текущего диалога. Jinja-шаблон с переменными: {{ variables.response }}.

Script Task

Короткий Python-скрипт внутри процесса для трансформации данных. Без обращений во внешние сервисы (для этого Service Task) — pure transformation.

Code — Python-код. Доступны: variables (read), outputs (dict для записи).

Outputs — поля, которые скрипт должен записать в outputs. Эти поля после успешного выполнения мержатся в variables процесса.

Timeout — секунды (>0). Дефолт — 5.

Реализован на RestrictedPython с whitelist'ом builtin'ов. Импорты, файловые операции, сетевые вызовы, метапрограммирование запрещены.

Atomicity — outputs относительно raise

Outputs применяются ТОЛЬКО при успешном завершении скрипта. Если в любом месте скрипта произошло raise — все ранее записанные outputs игнорируются: variables процесса остаются в состоянии ДО исполнения скрипта.

# Если raise срабатывает — ни counter, ни _processed_at не попадут в variables
outputs["counter"] = variables.get("counter", 0) + 1
outputs["_processed_at"] = "2026-05-06"

if some_invalid_condition:
    raise ValueError("validation failed")

После такого скрипта в variables не появится ни counter, ни _processed_at. В variables попадёт только error="..." и error_class="ScriptRuntimeError". Это важно для retry-loop'ов внутри WHILE/FOREACH error_strategy=continue — следующая итерация видит то же начальное состояние, без частичных побочных эффектов от упавшей итерации.

Это поведение реализовано на уровне ScriptExecutor (handler ловит exception → публикует только error без outputs), а не как RestrictedPython transactional rollback.

Asymmetry с Service Task

Script Task отбрасывает outputs при raise. Service Task сохраняет выходные данные при HTTP не-2xx (см. выше).

Если процесс должен «не применять переменные при ошибке» после Service Task — проверяй success/status_code в Exclusive Gateway вручную.

Exclusive Gateway

Ветвление по условию. Токен идёт только в одну ветку — первую, условие которой выполнилось.

Условия настраиваются на рёбрах, выходящих из Gateway. Кликните на ребро → конструктор условий: поле → оператор → значение.

Одно ребро можно сделать default (по умолчанию) — токен пойдёт туда, если ни одно условие не совпало.

Parallel Gateway

Параллельное выполнение. Все ветки запускаются одновременно. Процесс продолжается после join-точки только когда все ветки завершены.

Timer Event

Пауза в процессе. Задаётся длительность (ISO 8601 duration: PT5M, PT1H, P1D). После истечения — процесс продолжается.

Сервисные связи (Service Edge)

Обычные рёбра передают токен между узлами. Сервисное ребро дополнительно выполняет предобработку данных прямо на пути.

Когда использовать

  • STT → AI Chat — голосовое сообщение клиента автоматически транскрибируется, AI видит уже текст.
  • STT → AI Task — запись звонка → извлечение ключевых пунктов.
  • HTTP → AI Task — ответ внешнего API преобразуется перед передачей в следующий узел.

Настройка

Кликните на обычное ребро → в правой панели выберите Сервисное ребро → укажите тип обработки и параметры (например, провайдер STT).

Сервисное ребро не показывается как отдельный узел в процессе — это свойство связи, что упрощает граф.