ENНачать

Документация

Approvals

Approval — это human-in-the-loop gate внутри workflow'а: автоматика останавливается, ждёт пока назначенный человек подтвердит или отклонит. Без UI-подтверждения

Approval — это human-in-the-loop gate внутри workflow'а: автоматика останавливается, ждёт пока назначенный человек подтвердит или отклонит. Без UI-подтверждения — run в состоянии awaiting_approval, ничего не идёт дальше.

Зачем

Три стандартных use-case'а:

  1. Финансовые риски — «refund > 10 000 ₽ требует approval owner'а»
  2. Compliance — «массовые изменения в 1С проводит только бухгалтер»
  3. Качество LLM-output'а — «ответ AI-агента клиенту → approve менеджером → отправить»

Как добавить

В editor'е → нода approval.request:

approval.request
  title       = "Refund для сделки {{list.results.0.name}}"
  body        = "Сумма: {{trigger.object.amount.value}} ₽"
  assignedTo  = { kind: "role", role: "owner" }
  # или named user:
  # assignedTo = { kind: "user", userId: "uuid" }
  ttl         = 86400   # seconds; expired → auto-reject

Две выходные ветки ноды:

  • approved → run продолжается по этой ветке
  • rejected → run продолжается по второй (обычно — fail / retry / уведомить кого-то что отказано)

Inbox

Все pending-approvals собираются на /approvals:

  • Filter'ы по space / process / status / assigned_role
  • Каждая row открывается в drawer с deталями: trigger-payload, что просит agent, по какой сделке / заказу / run'у
  • Кнопки Approve / Reject + опциональный comment

Approval-события записываются в audit trail: кто когда что.

Роли

RoleСтандартно может approve
ownerвсё
adminвсё, кроме delete account / space-plan change
memberтолько approvals, where assignedTo.role == 'member' или assignedTo.userId == <их id>

Custom-роли не поддерживаются в v1 — плоская трёхуровневая иерархия.

SLA / TTL

ttl — сколько approval живёт до auto-reject'а. По умолчанию 24 часа (86400 sec). После — approval-request считается rejected with reason TIMEOUT, run идёт по rejected-ветке.

Длинные TTL (недельные) ок, но помните: run всё это время висит в awaiting_approval, не стареет сам по себе.

Re-request

Если approval отклонили по ошибке — выпустите новую revision с adjusted trigger'ом / workflow'ом, re-run failed runs. Старый rejected approval остаётся в audit'е навсегда.

Notifications

v1: approvals не слают push-уведомлений автоматически. Пока оператор должен заходить в /approvals. Workaround — добавить telegram.message.send параллельно approval.request:

approval.request (...)
telegram.message.send (chat_id = <manager>, text = "⏳ Нужен approval: https://summing.org/app/approvals")

Нативные notifications через email/Telegram/push — backlog'ом после B3 email-integration стабилизируется.

API

  • POST /approvals/<id>/approve — approve
  • POST /approvals/<id>/reject — reject (с опциональным comment'ом)
  • GET /approvals?status=pending — list

Публичную HTTP-схему держим отдельно от пользовательской документации; для интеграций обычно достаточно UI-шаблонов и cookbook-примеров.

Связанное