Baserow подходит для новой таблицы заявок, где сотрудники заполняют исходные данные, ИИ-агент предлагает решение, а ответственный человек утверждает обновление. Для начала нужны схема полей, статусы и отдельные права на чтение и запись. Такой контур полезен, когда команда готова вести новый поток заявок с ясной историей решений.
Новая таблица
По документации Baserow, таблицу можно создать с нуля и настроить типы полей под свой процесс. Для работы с ИИ-агентом храните исходную заявку и предложение модели в разных полях.
Возьмём условный поток внутренних заявок на ремонт оборудования. Сотрудник описывает неисправность и указывает объект. Агент предлагает категорию обращения и список уточняющих вопросов. Диспетчер сверяет предложение с заявкой, исправляет спорные детали и назначает ответственного. В такой схеме Baserow служит новым журналом работы команды. Заявка поступает в него по заранее согласованной форме, а итоговое решение остаётся за человеком.
Для процесса с уже работающей SQL-базой задача иная: там интерфейс подключают к действующим таблицам и отдельно проверяют влияние правок на существующие записи. Здесь команда проектирует новую таблицу заявок, поэтому может сразу заложить статусы, владельца и след изменений. Общие no-code варианты для строительной компании раскрыты в статье об автоматизации стройки; текущая схема сосредоточена на одной таблице и порядке её обновления.
- Определите, кто создаёт заявку и какие сведения он вправе указать.
- Разделите текст автора, предложение агента и утверждённое решение.
- Назначьте человека, который переводит спорную заявку в дальнейшую работу.
Сначала опишите маршрут на бумаге: от сообщения сотрудника до подтверждённой карточки. Если итог должен попасть в другую систему, запишите место передачи и ответственного за неё. Достоверность сведений для внешнего процесса подтверждает отдельная сверка, даже если таблица уже заполнена. Критерием готовности станет возможность восстановить путь каждого утверждённого значения до исходной заявки и решения диспетчера.
Поля и статусы
Схему стройте вокруг вопроса диспетчера: что произошло, где это случилось и какое решение уже принято. У каждой строки должен быть устойчивый идентификатор. Версию для согласования храните в отдельном поле или журнале собственного сервиса. Добавьте источник заявки, объект, исходное описание, автора, состояние проверки, предложенную категорию, утверждённую категорию и владельца решения. Поля, нужные только для вывода модели, держите отдельно от полей, по которым команда действует. Так ошибочное предложение видно, но оно сохраняет статус черновика.
| Поле | Зачем хранить | Кто сверяет |
|---|---|---|
| Описание и объект | Сохраняют исходный смысл заявки | Автор и диспетчер |
| Предложенная категория | Показывает гипотезу агента | Диспетчер |
| Утверждённая категория | Определяет маршрут работы | Ответственный за решение |
| Статус и версия | Показывают этап и актуальность строки | Сервер процесса |
Статусы задайте как допустимые этапы: новая, уточняется, ожидает согласования, утверждена, возвращена автору. Для каждого перехода напишите условие. Например, утверждение требует заполненного объекта и проверенной категории. Форму Baserow можно использовать для приёма новых строк: официальное руководство поясняет, что отправка формы сразу создаёт строку. Поэтому обязательные поля формы защищают вход, а итоговое утверждение вынесите в отдельный шаг.
Проверьте схему на условных сложных заявках: пустой объект, похожие категории, повторное обращение об одной неисправности. Скрипт выявляет пустые поля и дубликаты по согласованным ключам. Языковая модель помогает объяснить описание и предложить гипотезу категории. Диспетчер сверяет её с исходным текстом и правилами маршрутизации. Контрольный список выбранных заявок и решений собирайте скриптом, чтобы результат можно было повторно проверить.
Права участников
До подключения агента распределите действия между автором, диспетчером и сервисом процесса. Автор создаёт заявку и видит её статус. Диспетчер читает исходный текст и меняет проверяемые поля. Агент получает только сведения, необходимые для предложения категории. Сервер сохраняет результат после проверки прав и текущего состояния строки. Такая схема ограничивает последствия ошибочного ответа модели: она описывает вариант, а запись утверждённого решения происходит по правилам приложения.
Baserow описывает права на уровне рабочих областей и таблиц, а также ограничения изменения отдельных полей. Детальные роли и права полей относятся к платным редакциям Advanced и Enterprise; перед запуском сверьте доступность в документации Baserow и выбранном тарифе. Скрытие колонки в представлении помогает интерфейсу, но для защиты чувствительного значения нужны реальные ограничения доступа. Проверьте сценарии под учётными записями разных ролей, включая обращения через API.
- Назначьте владельца таблицы и утвердите перечень ролей команды.
- Разрешите сотруднику создавать исходную заявку и видеть предусмотренные поля.
- Проверьте, какие поля диспетчер вправе исправлять, а какие доступны только серверному шагу.
- Выдайте интеграции отдельный токен с минимальными операциями для нужной таблицы.
- Проведите пробный запрос к запрещённому полю и зафиксируйте фактический отказ.
Для API Baserow поддерживает токены с правами на чтение, создание, обновление и удаление строк по таблицам, согласно документации API. Токен храните на сервере процесса. Проверка полномочий сотрудника перед утверждением тоже живёт на сервере; промпт агента может напомнить о согласовании, но технический допуск определяют сервер и настройки доступа.
Согласование обновления
Рабочий маршрут начинается с новой строки. Сервер считывает заявку с допустимым статусом, проверяет обязательные поля и передаёт агенту разрешённое описание. Агент возвращает предложенную категорию и вопросы для диспетчера. Сервер записывает их в поля черновика, сохраняя исходный текст без изменений. Диспетчер открывает строку, сверяет предложение с источником и выбирает утверждение, исправление либо возврат автору.
При утверждении сервер перечитывает строку. Он проверяет личность сотрудника, его право на операцию, состояние заявки и актуальность версии, показанной в интерфейсе. Если автор успел поменять описание, диспетчер получает свежую запись для повторной сверки. Утверждённую категорию сервер сохраняет только после успешной проверки. При параллельной работе простого чтения перед записью недостаточно: проводите утверждения через очередь одного серверного процесса или другой механизм атомарного контроля версии. Такой порядок нужен и при работе через API: фраза «согласовано» в ответе модели остаётся текстом; право изменения даёт успешная серверная проверка.
- Сравните предложенную категорию с текстом и объектом исходной заявки.
- Проверьте, остались ли открытые вопросы к автору.
- Убедитесь, что версия строки совпадает с просмотренной диспетчером.
- Зафиксируйте имя ответственного и основание утверждения либо возврата.
Для внутреннего заказа похожую границу между черновиком и решением показывает материал об ИИ-агенте для заказов. В Baserow этот принцип выражается полями заявки и проверяемым переходом статуса. Если процесс связан с CRM, пригодится разбор карточки, подсказки и контроля; итоговая система получает только подтверждённое значение. В журнале переходов сохраняйте основание решения и ссылку на исходное описание. Такая запись помогает сменному диспетчеру увидеть, почему заявка получила именно этот статус, и какие вопросы остались открытыми.
Хотите согласовать обновления заявок перед записью агентом?
История и пилот
История строки помогает разобрать спор: кто изменил категорию, какое значение было раньше и когда появилась правка. Руководство Baserow описывает просмотр изменений строки и прежних значений. Эта история служит материалом для расследования; возможность восстановления и срок хранения сверяйте с вашей редакцией. Для важных переходов дополнительно сохраняйте журнал приложения: идентификатор заявки, версию, предложение агента, решение человека и результат серверной проверки.
Пилот предложите на обезличенных внутренних заявках одного типа. Создайте новую таблицу, проверьте форму входа, затем запустите сценарий с предложением категории и ручным утверждением. Заранее запишите критерии: все обязательные поля заполнены, ошибочная категория остаётся черновиком, изменение исходного описания возвращает строку на сверку, история объясняет итог. После проверки команда сможет решить, нужен ли больший поток и какие исключения ещё требуют правил.
Возьмите несколько обезличенных заявок с понятным владельцем решения. Сначала согласуйте поля и статусы на этих примерах, затем проверьте запрет утверждения устаревшей версии строки. Типичная ошибка здесь состоит в записи ответа агента прямо в итоговое поле; отдельный черновик сохраняет место для проверки человеком.
Если подтверждение оказалось ошибочным, ответственный сверяет прежнее значение с историей и исходной заявкой. Возврат выполняет сервер после проверки прав и сохранения причины корректировки. Затраты на настройку зависят от сложности формы, ролей, интеграций и требований к истории; тарифы Baserow уточняйте на актуальной странице сервиса. Если нужен такой процесс для команды, опишите задачу на странице об ИИ-агентах для бизнеса. Мы оценим состав работ по вашей схеме заявок.