ToolJet — конструктор внутренних приложений, на котором за одну сборку получается экран оператора: таблица обращений, карточка с подсказкой ИИ и кнопка подтверждения. Такой экран нужен, когда автоматизация обрабатывает основной поток сама, а спорные случаи ждут человека. Для одного отдела с понятным списком действий конструктор подойдёт, для процесса с десятками ролей и сложной отчётностью выгоднее заказная разработка.
Зачем нужен экран
ToolJet соединяет источники данных с таблицами, формами и кнопками. На них строят экран, где оператор видит исключения автоматизации, читает подсказку модели и сам решает, что записать в систему.
Автоматизация обычно обрабатывает типовые случаи и останавливается на странных: счёт без номера заказа, обращение с двумя противоречивыми просьбами, договор с нестандартным пунктом. Эти случаи копятся в логах, и разбирать их некому. Панель оператора превращает их в очередь с владельцем. Про то, как выглядит такой маршрут целиком, есть материал про no-code автоматизацию на примере строительной компании; здесь разбирается только экран.
В документации ToolJet описаны источники данных, запросы к ним, виджеты вроде таблицы, кнопки и формы, а также workflows для автоматизации процессов. Для панели хватает трёх сущностей: подключение к базе или API, запрос, который читает очередь, и кнопка, которая отправляет решение обратно. Возможности сверх этого проверяйте на своей версии, потому что набор функций зависит от редакции и способа установки.
Принцип распределения ролей такой. Скрипт или система собирает полные данные, модель объясняет случай и предлагает действие, оператор сверяет предложение с первичными документами, а права и подтверждение проверяет сервер. Решения принимает человек и сервер, а интерфейс лишь показывает данные: скрыть кнопку в экране мало, потому что запрос можно отправить напрямую.
Условный пример: небольшой отдел получает счета от поставщиков. Скрипт сверяет реквизиты и сумму с заказом, и большая часть счетов проходит без людей. Расхождения остаются в очереди с пометкой «сумма расходится с заказом». Оператор открывает случай, видит оба документа и подсказку модели, решает сам и фиксирует ответ. Остальные сотрудники освобождены от просмотра всех счетов подряд, и время уходит на сложные случаи.
Источник данных
Экран читает очередь из одного места. Заведите таблицу исключений в базе или в учётной системе: идентификатор случая, ссылка на исходный документ, причина остановки, предложение модели, статус и ответственный. Подключение в ToolJet создают через раздел источников данных; по описанию в документации поддерживаются базы данных, API и внешние сервисы.
- Для чтения очереди заведите отдельную учётную запись базы с правом только на нужную таблицу.
- Для записи решения оператора заведите вторую запись с правом менять статус, но без права удалять строки.
- Поле с предложением модели храните отдельно от поля с решением человека, чтобы позже сравнивать их.
- Ссылку на исходный документ делайте активной: оператору важнее увидеть первичный файл, чем пересказ.
Запрос на чтение ограничьте условием: только случаи со статусом «ждёт решения» и только для отдела текущего оператора. Лимит на число строк в выдаче ставьте на уровне запроса. Если данные клиентов попадают в очередь целиком, сократите поля до необходимых: телефону и адресу в таблице исключений обычно нечего делать. Общие принципы разграничения доступа разобраны в статье про права, секреты и проверку ИИ-агентов.
Перед запуском проведите проверку записи и чтения на тестовой таблице: добавьте три вымышленных случая, откройте их на экране, подтвердите один, отклоните другой и убедитесь, что статус в базе изменился ровно у выбранных строк. Затем зайдите под учётной записью без прав на подтверждение и проверьте, что сервер отвечает отказом.
Очередь исключений
Главный элемент экрана — таблица со случаями. Колонки подбирайте под решение оператора, а удобство программиста идёт вторым: что случилось, насколько давно случай ждёт, что предлагает модель и чем это подкреплено. Подкрепление важно: подсказка без ссылки на фрагмент документа заставляет оператора верить на слово.
| Колонка | Откуда данные | Зачем оператору |
|---|---|---|
| Причина остановки | Правило автоматизации | Понять, где процесс остановился |
| Предложение модели | Ответ модели, сохранённый скриптом | Получить черновик решения для проверки |
| Основание | Ссылка на фрагмент исходного документа | Сверить предложение с первичным источником |
| Возраст случая | Дата попадания в очередь | Разобрать самые старые первыми |
Сортировку по возрасту сделайте режимом по умолчанию. Если очередь растёт быстрее, чем её разбирают, это сигнал о проблеме процесса, и руководителю нужен счётчик просроченных случаев на отдельном виджете. Стандартные виджеты ToolJet покрывают таблицу, форму и кнопку, а нужные вам нестандартные элементы проверяйте в документации перед тем, как обещать их заказчику.
Какие случаи в вашем процессе сейчас останавливаются и ждут человека?
Кнопка подтверждения
Кнопка запускает запрос, который записывает решение. Здесь проходит граница между подсказкой и действием. Запрос отправляет на сервер идентификатор случая, выбранное действие и имя оператора, а сервер сам определяет, разрешено ли это действие данной роли и находится ли случай в нужном статусе.
- Оператор открывает случай и читает основание рядом с предложением модели.
- Оператор выбирает действие из короткого списка: принять предложение, изменить, вернуть на доработку, отклонить.
- Для изменения система требует комментарий в одну строку. Пустой комментарий отклоняется на сервере.
- Сервер проверяет роль, статус случая и версию записи, чтобы два оператора сохраняли изменения по очереди.
- Результат пишется в журнал: кто, когда, какое действие, что предлагала модель.
Журнал решает два вопроса сразу. Во-первых, он помогает разбирать спорные случаи: видно, кто подтвердил запись и на каком основании. Во-вторых, он показывает качество подсказок: если операторы принимают предложение почти всегда, проверка становится формальной и её полезно усилить, а если отклоняют часто, надо менять инструкцию модели или состав входных данных.
Для спорных случаев добавьте действие «передать руководителю» с обязательным комментарием. Оно разгружает оператора, когда решение выходит за его полномочия, и оставляет в журнале след эскалации. Состав действий согласуйте с владельцем процесса до сборки экрана, поскольку каждое новое действие требует серверного правила и отдельного теста.
Сравнение на кейсе
Выбирая между ToolJet и другими конструкторами внутренних приложений, например Budibase, сравнивайте на одном и том же условном кейсе, вместо списка функций с сайтов. Возьмите очередь из пяти колонок и одну кнопку с серверной проверкой. Засеките, сколько времени займёт сборка, насколько ясно, что происходит при ошибке запроса, и как выглядит разграничение ролей. Любые обещания возможностей сверяйте с документацией выбранной версии.
Отдельный пункт — условия лицензии и способ установки. Репозиторий ToolJet на GitHub указывает лицензию AGPL-3.0, а документация описывает развёртывание на своей инфраструктуре через Docker, Kubernetes и облачные платформы. Для внутреннего использования это обычно рабочий вариант, но юристу компании полезно прочитать условия, особенно если конструктор встраивают в продукт для клиентов. Размещение на своём сервере добавляет обязанность по обновлениям и резервным копиям.
Экран оператора — лишь часть процесса. Саму автоматизацию, которая наполняет очередь, строят на платформе вроде n8n; сравнение вариантов есть в статье n8n или Make. Вместе они дают контур, где поток идёт без людей, а исключения доходят до человека с понятным основанием.
Возьмите один тип исключений, например счета без номера заказа, и опишите на листе пять колонок экрана и три действия оператора. Соберите эту панель на тестовых данных и дайте её попробовать двум сотрудникам. Если экран нужен частью проекта с ролями, журналом и приёмкой, смотрите раздел про внедрение ИИ под ключ.