Бипуим: Документация
8-800-505-24-05Сайт Бипиум
  • 😎Отвечаем на ваши вопросы
  • 🎂Версии и обновления
  • ❗Обновление до версии 2.0
  • Документация
    • 🆕С чего начать
      • Регистрация и вход
      • Создаем каталоги и записи
      • Формируем отчёты
      • Настраиваем правовую политику
      • Применяем автоматизации
    • ⚙️Конструктор данных
      • Отделы
      • Каталоги
        • Редактирование структуры
        • Настройка отображения
        • Поиск и фильтрация
        • Импорт записей
          • 📗Импорт из Excel
        • Экспорт записей
        • Активность
      • Системные каталоги
        • Сотрудники
        • События
        • Внешние запросы
        • Сценарии
        • Процессы
        • Доступ к сервисам
        • Вебхуки
      • Виды
      • Записи
    • 📊Отчеты
      • Графики
    • 🔑Права
      • Правила
      • Привилегии
      • Правовые группы
      • Правовые виды
      • Права на поля
      • Комбинация прав
    • 🤖Автоматизации
      • События
        • Изменение данных
        • Внешние запросы
      • Сценарии
        • Компоненты
          • Начало процесса
          • Конец процесса
          • Таймер
          • Ошибка
          • Шлюз «ИЛИ» (условное ветвление)
          • Шлюз «И» (распараллеливание)
          • Получить запись
          • Найти записи
          • Изменить запись
          • Создать запись
          • Удалить запись
          • Структура каталога
          • Загрузить файл
          • Сгенерировать документ
          • Назначение переменных
          • Код (Javascript)
          • Веб-запрос
          • SQL-запрос
          • Конвертер
          • Парсер
          • Запуск процесса
          • Получение почты
          • Отправка почты
          • Соединяющая линия
          • Отправить сообщение
        • Переменные
        • Выражения
        • Входные и выходные параметры компонентов
        • Примеры настройки
          • Условие
          • Цикл
      • Ограничения
  • Лицензии
    • 🌐Тип лицензирования
  • Примеры
    • 🔑Права доступа к данным
    • 🤖Автоматизации
      • Выгрузка файлов на Яндекс Диск
      • Отправка на больничный
      • Автоматизация оплаты счетов
      • Создание наименований записей
      • Расчет скидок для клиентов
      • Запрет на создание дубликатов в каталоге
      • Автозаполнение данных по ИНН
      • Переброс данных между связанными каталогами
      • Очередь сценариев
      • Отслеживание заявок с сайта помощью UTM-меток
      • Просрочка задач по дедлайну
      • Реализация механизма согласования записей
      • Массовое изменение записей
      • Создание каталога для рассылки почты
      • Перенос данных между системами Бипиума
      • Импорт данных из Excel
      • Генерация счет-фактуры
      • Генерация excel-отчетов
      • Планировщик задач
      • Импорт банковских выписок
      • Производственный календарь
      • Складской учет
  • Интеграции
    • 🥂Методы интеграции
      • Интеграция данных
        • API
        • Вебхуки (webhooks)
      • Интеграция интерфейса
        • Веб-формы
        • Веб-расширения
      • Примеры интеграций
        • Тильда
          • Прием данных с формы Tilda
          • Интеграция веб-интерфейса в Tilda
        • Интеграция с сервисом «DaData»
        • Интеграция c «Единой информационной системой в сфере закупок»
        • Мессенджеры
          • Интеграция с Telegram-ботом
        • Почтовые сервисы
          • UniSender
          • MailChimp
        • Сервисы Google
          • Google Calendar
        • Телефония
          • Oktell
            • Панель телефонии Oktell
            • Компонент Bpium в Oktell
        • 1C
    • 🔌API
      • Данные
        • Каталоги (Catalogs)
        • Записи (Records)
        • Связи (Relations)
        • Истории (Histories)
        • Файлы (Files)
        • Отделы (Sections)
        • Виды (Views)
        • Сообщения (Messages)
      • Агрегация
        • Разложения (Values)
        • Сводка (Totals)
      • Отчеты
        • Дашборды (Boards)
        • Графики (Widgets)
      • Поисковые выборки
        • Доступные связи (AvailableRecords)
        • Доступные условия фильтра (AvailableFilterRecords)
        • Сотрудники (Users)
        • Контакты (Contacts)
      • Права (Rights)
      • Профиль (Profile/me)
  • Установка на сервер
    • 🧱Архитектура
      • Варианты разворачивания
    • 🖥️Требования
    • 📂Установка как служба
    • 🛳️Установка через Docker
    • 🎛️Мультидоменная среда
    • 🆘Материалы
      • TLS/SSL Сертификат
      • Параметры config.env
        • Для Bpium
        • Для Bpium S3
        • Для Bpium BPM
      • Запуск
      • Обсуживание
        • Активация
        • Обновление
        • Бэкап и восстановление базы
        • Брендирование (Whitelabel)
        • Удаление
      • Перенос базы из облака
      • Возможные проблемы в ходе установки и работы
  • Обучение
    • Базовый курс
      • Урок 1. Отделы
      • Урок 2. Каталоги с данными
      • Урок 3. Карточки записей
      • Урок 4. Связи между данными
      • Урок 5. Фильтры и виды
      • Урок 6. Приглашение сотрудников
      • Урок 7. Права доступа к данным
      • Урок 8. Графические отчеты
      • Урок 9. Бизнес-процессы
      • Урок 10. Интеграции
    • Технический курс
      • Урок 1. Принцип работы автоматизаций
      • Урок 2. Первая автоматизация изнутри
      • Урок 3. Валидация данных
      • Урок 4. Простые вычисления
      • Урок 5. Расчет суммы заказа
      • Урок 6. Генерация счетов/документов
      • Урок 7. Рассылка почтовых сообщений
      • Урок 8. Прием внешних данных
      • Урок 9. Отправка данных на сторонние сервисы
    • Паттерны проектирования ИС
      • Унификация
      • Упорядоченность
      • Разделение
      • Актуализация
      • Вынос параметров
      • Выделение позиций
      • Слияние
      • Дублирование
      • Типизация
      • Информирование
Powered by GitBook
On this page
  • Подписка на событие
  • События
  • Уведомление о создании записи (after create)
  • Уведомление об изменении записи (after update)
  • Уведомление об удалении записи (after delete)
  • Запрос на создание записи (before create)
  • Запрос на изменение записи (before update)
  • Запрос на удаление записи (before delete)
  • Изменено поле во время редактирования (updating)
  • Структура объекта values, allValues, prevValues
  1. Документация
  2. Автоматизации
  3. События

Изменение данных

Запуск процесса при изменении данных в Бипиуме: создании, изменении, удалении записей.

PreviousСобытияNextВнешние запросы

Last updated 2 years ago

Подписка на событие

  • В отделе «Управление» в каталоге «» добавьте новую запись (событие, по которому будет запускаться процесс).

  • Укажите название для быстрой идентификации. Например, кратко опишите задачу, которую выполняет процесс.

  • Выберите каталог, в котором хотите отслеживать изменение записей.

  • Выберите тип события для запуска сценария. Подробнее в статье «».

  • В поле «Выполнить» выберите или создайте новый сценарий.

События

События делятся на уведомления, запросы и действия:

  • Уведомления (after) срабатывают после сохранения изменений в базу, то есть поле того, когда запись уже создана, изменена или удалена

  • Запросы (before) срабатывают перед тем как данные сохранены в базу, то есть непосредственно во время срабатывания события в данных в базе еще нет. Эти события могут отменить операцию сохранения/изменения/удаления записи.

  • Действия срабатывают во время редактирования записи сотрудником, еще до того как он отправил данные на сохранения. Эти события могут подменять значения полей в карточке на экране сотрудника без сохранения их в базу.

Уведомление о создании записи (after create)

Срабатывает ПОСЛЕ того как создана новая запись в каталоге, и эта операция сохранена в базу.

event: {
    id: "1",
    type: "$record.after.create",
    async: true
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
recordId: "1234",
values: {
    "2": "Record Title", // текстовое поле
    "14": 123 // числовое поле
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге События.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник, вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс (событие вызвано системой).

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором создана запись.

  • recordId(строка) — идентификатор созданной записи.

  • values(объект) — коллекция значений заполненных полей созданной записи. Ключи объекта — идентификаторы (ID) заполненных полей. Формат описан ниже.

События типа уведомлений (after) не ожидают ответа.

Уведомление об изменении записи (after update)

Срабатывает ПОСЛЕ того как запись в каталоге была изменена, и эта операция сохранена в базу.

event: {
    id: "2",
    type: "$record.after.update",
    async: true
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
recordId: "1234",
values: {
    "2": "Title", // текстовое поле
    "14": 4562, // поле число
    "15": "2017-10-11T08:01:28:000Z1" // поле дата
},
prevValues: {
    "2": "Record Title", // текстовое поле
    "14": 123 // числовое поле
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге Событий.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс (событие вызвано системой).

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором изменили запись.

  • recordId(строка) — идентификатор измененной записи.

  • values(объект) — коллекция значений измененных полей измененной записи. Ключи объекта — идентификаторы (ID) измененных полей. Формат описан ниже.

  • prevValues(объект) — коллекция предыдущих значений всех полей записи. Формат аналогичен объекту values.

События типа уведомлений (after) не ожидают ответа.

Уведомление об удалении записи (after delete)

Срабатывает ПОСЛЕ того как запись в каталоге была удалена и эта операция сохранена в базу.

event: {
    id: "3",
    type: "$record.after.delete",
    async: true
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
recordId: "1234",
values: {
    "2": "Title", // текстовое поле
    "14": 4562, // поле число
    "15": "2017-10-11T08:01:28:000Z1", // поле дата
    "16": [ // поле связанный объект
        {
            "sectionId": "3",
            "catalogId": "5",
            "catalogTitle": "Клиенты",
            "catalogIcon": "users-10",
            "recordId": "33",
            "recordTitle": "Место работы"
        }
    ]
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге Событий.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс.

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором удалили запись

  • recordId(строка) — идентификатор удаленной записи

  • values(объект) — коллекция значений всех полей удаленной записи. Ключи объекта — идентификаторы (ID) всех полей. Формат описан ниже.

События типа уведомлений (after) не ожидают ответа.

Запрос на создание записи (before create)

Срабатывает ДО того как создана новая запись в каталоге, данные еще не сохранены в базу и могут быть отменены событием.

event: {
    id: "4",
    type: "$record.before.create",
    async: false
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
values: {
    "2": "Record Title", // текстовое поле
    "14": 123 // числовое поле
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге Событий.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс (событие вызвано системой).

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором хотят создать запись

  • values(объект) — коллекция значений заполненных полей созданной записи. Ключи объекта — идентификаторы (ID) заполненных полей. Формат описан ниже.

recordId отсутствует, так как запись в базе еще не создана и ей не присвоен ID.

Как проверить задан ли recordId?

Если вы используете один и тот же сценарий на изменение записи и на создание, то вероятно захотите узнать, задан ли recordId или нет. Если вы проверите наличие выражением ! recordId, то процесс завершится с ошибкой, когда параметр не задан. Так происходит так как переменная не определена.

Проверить наличие входного параметра можно с помощью шлюза «или». Для этого на выходящую из шлюза ветку, которая соответствует отсутствию параметра recordId, нужно задать условиеtypeof recordId === 'undefined'. А на вторую ветку, которая соответствует ситуации, когда параметр recordId задан: typeof recordId !== 'undefined'.

Событие ожидает разрешения применить или заблокировать сохранение данных.

$status = 400
$body = {
    "message": "Не верно указано поле 2",
    "values": {
        "2": "Extra new Title", //Текстовое поле
        "14": 999, //Поле число
    }
}
    • 200 — разрешить операцию

    • 4xx (например, 400) — запретить операцию и выдать ошибку

  • $body(объект) — объект с дополнительными параметрами:

    • message (строка) — сообщение для отображения сотруднику, в случае запрета.

    • values (объект) — коллекция значений полей для подстановки в карточку. Ключи объекта — идентификаторы (ID) полей. Формат описан ниже.

Запрос на изменение записи (before update)

Срабатывает ДО того как изменения записи сохранены в базу, и могут быть отменены событием.

event: {
    id: "5",
    type: "$record.before.update",
    async: false
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
recordId: "1234",
values: {
    "2": "Title", // текстовое поле
    "14": 4562, // поле число
    "15": "2017-10-11T08:01:28:000Z1" // поле дата
},
prevValues: {
    "2": "Record Title", // текстовое поле
    "14": 123 // числовое поле
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге Событий.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс (событие вызвано системой).

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором изменили запись.

  • recordId(строка) — идентификатор измененной записи.

  • values(объект) — коллекция значений измененных полей измененной записи. Ключи объекта — идентификаторы (ID) измененных полей. Формат описан ниже.

  • prevValues(объект) — коллекция предыдущих значений всех полей записи. Формат аналогичен объекту values.

Событие ожидает разрешения применить или заблокировать сохранение данных.

$status = 400
$body = {
    "message": "Не верно указано поле 2",
     "values": {
        "2": "Extra new Title", //Текстовое поле
        "14": 999, //Поле число
    }
}
    • 200 — разрешить операцию

    • 4xx (например, 400) — запретить операцию и выдать ошибку

  • $body(объект) — объект с дополнительными параметрами:

    • message (строка) — сообщение для отображения сотруднику, в случае запрета.

    • values (объект) — коллекция значений полей для подстановки в карточку. Ключи объекта — идентификаторы (ID) полей. Формат описан ниже.

Запрос на удаление записи (before delete)

Срабатывает ДО того как изменения записи сохранены в базу, и могут быть отменены событием.

event: {
    id: "6",
    type: "$record.before.delete",
    async: false
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
recordId: "1234",
values: {
    "2": "Title", // текстовое поле
    "14": 4562, // поле число
    "15": "2017-10-11T08:01:28:000Z1", // поле дата
    "16": [ // поле связанный объект
        {
            "sectionId": "3",
            "catalogId": "5",
            "catalogTitle": "Клиенты",
            "catalogIcon": "users-10",
            "recordId": "33",
            "recordTitle": "Место работы"
        }
    ]
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге Событий.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс.

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором удалили запись

  • recordId(строка) — идентификатор удаленной записи

  • values(объект) — коллекция значений всех полей удаленной записи. Ключи объекта — идентификаторы (ID) всех полей. Формат описан ниже.

Событие ожидает разрешения применить или заблокировать сохранение данных.

$status = 400
$body = {
    "message": "Не верно указано поле 2"
}
    • 200 — разрешить операцию

    • 4xx (например, 400) — запретить операцию и выдать ошибку

  • $body(объект) — объект с дополнительными параметрами:

    • message (строка) — сообщение для отображения сотруднику, в случае запрета.

Изменено поле во время редактирования (updating)

Срабатывает ВО ВРЕМЯ того как сотрудник редактирует карточку записи. Изменения еще не отправлены на сервер и вообще могут быть не сохранены. Событие может вернуть новые данные полей, которые будут подставлены в карточку на экране сотрудника.

Событие поддерживается начиная с версии 1.5.2.

event: {
    id: "7",
    type: "$record.updating",
    async: false
},
script: {
    id: "7"
},
user: {
    id: "2"
},

catalogId: "15",
recordId: "1234",
values: {
    "2": "New title" // текстовое поле
}
allValues: {
    "2": "Title", // текстовое поле
    "14": 4562, // поле число
    "15": "2017-10-11T08:01:28:000Z1", // поле дата
    "16": [] // категории, набор галочек
}

Общие параметры событий

  • event(объект) — параметры сработавшего события. Доступно с версии 1.5.2.

    • id(строка) — идентификатор события в каталоге Событий.

    • type(строка) — название типа события.

    • async(булево) — признак запуска: true — асинхронно, false — синхронно.

  • script(объект) — параметры запущенного сценария. Доступно с версии 1.5.2.

    • id(строка) — идентификатор сценария в каталоге Сценарии.

  • user(объект) — сотрудник вызвавший событие.

    • id(строка) — идентификатор сотрудника или null, если вызвал другой процесс (событие вызвано системой).

Дополнительные параметры события

  • catalogId(строка) — идентификатор каталога, в котором редактируют запись

  • recordId(строка) — идентификатор редактируемой записи. Если сотрудник редактирует новую запись, то переменная recordId будет не задана.

  • values(объект) — коллекция значений измененных полей, вызвавших событие. Позволяет узнать какое именно поле менял сотрудник, изменяя запись. Ключи объекта — идентификаторы (ID) измененных полей. Формат описан ниже.

  • allValues(объект) — коллекция значений всех полей редактируемой записи. Ключи объекта — идентификаторы (ID) всех полей. Формат аналогичен values.

recordId может отсутствовать для новых записей.

Как проверить задан ли recordId?

Если вы проверите наличие recordIdвыражением ! recordId, то процесс завершится с ошибкой, когда параметр не задан. Так происходит так как переменная не определена.

Проверить наличие входного параметра можно с помощью шлюза «или». Для этого на выходящую из шлюза ветку, которая соответствует отсутствию параметра recordId, нужно задать условиеtypeof recordId === 'undefined'. А на вторую ветку, которая соответствует ситуации, когда параметр recordId задан: typeof recordId !== 'undefined'.

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

$body = {
    "message": "Не верно указано поле 2",
    "values": {
        "2": "Extra new Title", // текстовое поле
        "14": 999, // поле число
    }
}
  • $body(объект) — объект с дополнительными параметрами:

    • message (строка) — сообщение для отображения сотруднику, в случае запрета.

    • values(объект) — коллекция значений полей для подстановки в карточку. Ключи объекта — идентификаторы (ID) полей. Формат описан ниже.

Этот тип события не поддерживался в версиях Бипиума ранее 1.5.2. Реализовать поддержку события можно было используя механизм вебхуков.

Через вебхуки

  • Во время изменения данных сработает созданный вебхук.

  • Получив запрос на этот адрес, Бипиум запустит связанный с ним процесс.

  • Процесс на вход получит те же данные, которые получил вебхук.

  • После того как ваш процесс отрабатывает, он вернет результаты Бипиуму, Бипиум перешлет их вебхуку, вебхук пробросит результат процесса сотруднику в его открытое приложение.

Коротко: Изменение данных → вебхук → (веб-запрос) → внешний запрос → процесс → (результат) → Бипиум → вебхук → карточка, открытая у сотрудника.

Структура объекта values, allValues, prevValues

Все события во входных параметрах содержат объект values — значения всех полей созданной/измененной записи. Ключи объекта — идентификаторы полей. Формат значений для разных типов полей разный:

  • Однострочный текст = "Однострочный текст"

  • Многострочный текст = "Многострочный текст"

  • Дата = "2015-11-06T21:00:00.000Z"

  • Категория / набор галочек = [2] или несколько значений [2,3,4], без значения []

  • Вопрос = 2

  • Число = 3.2

  • Прогресс = 28(допустимо от 0 до 100)

  • Звезды = 5 (допустимо от 0 до 5)

  • Контакт = массив объектов:[ {"contact": "8-901-234-56-78", comment: "Секретарь"}, {...} ]

  • Связанная запись = массив объектов: [ {catalogId: '11', recordId: '91', catalogTitle: 'Название каталога', recordTitle: 'Название записи', isRemoved: false}, {...} ]

  • Сотрудник = массив объектов: [ {id: '21', title: 'Имя', isRemoved: false}, {...} ]

  • Файл = массив объектов:

Как получить значение измененного поля?

Как получить значение сложного поля?

Для сложных типов полей (значения которых представлены массивом, например: категория, связанный объект, контакт, сотрудник, файл) значение переменной будет равно массиву. Чтобы узнать сколько значений в массиве используйте выражение values['4'].length, а чтобы получить значение, например, 0-го элемента массива: values['4'][0], чтобы обратится к его свойству, например recordId у поля типа связанный объект: values['4'][0].recordId.

Однако, если вы обратитесь к параметру (например recordId) к элементу массива, которого нет (например, когда поле не было изменено, и в values нет ключа с идентификатором поля), то сценарий прервется с ошибкой. Поэтому, прежде чем получить свойство у объекта в массиве, нужно сначала проверить что массив не пустой. А прежде чем проверить, что он не пустой, нужно проверить что он существует (поле было изменено и в values есть ключ с этим идентификатором). Это можно сделать с помощью компонентов ветвления сценария (шлюзов) и проверки условий на исходящих соединительных линиях, или с помощью выражения: values['4'] && values['4'].length && values['4'][0].recordId.

Это выражение проверяет наличие изменения в 4-м поле, и если оно есть, то проверяет что в 4-м поле в массиве есть они элементы, и если есть хотя бы одно, то берется значение свойства recordId в 0-м элементе. Именно это значение будет присвоено переменной. Если что-то не выполняется, то переменной будет присвоено false.

Чтобы вернуть значения как результат процесса, нужно создать переменные в сценарии с такими названиями до компонента «Конец процесса», например с помощью компонента «».

$status(число) — код :

Чтобы вернуть значения как результат процесса, нужно создать переменные в сценарии с такими названиями до компонента «Конец процесса», например с помощью компонента «».

$status(число) — код :

Чтобы вернуть значения как результат процесса, нужно создать переменные в сценарии с такими названиями до компонента «Конец процесса», например с помощью компонента «».

$status(число) — код :

Чтобы вернуть значения как результат процесса, нужно создать переменные в сценарии с такими названиями до компонента «Конец процесса», например с помощью компонента «».

Вонеобходимо создать адрес для обращения вебхука.

На это событие, нужно создать «во время редактирования».

В качестве адреса вебхука должен быть указан адрес , который слушает Бипиум.

[ {title: "имя", url: "http://путь", size: 45654, mimeType: "image/png"}, {...} ] где mimeType— ​

Чтобы получить значение, например, 4-го поля в измененных данных, используйте компонент и укажите выражение values['4']. Если 4-е поле было изменено, вы получите его значение, если нет, то переменная будет пуста.

🤖
Назначение переменных
http-ответа
Назначение переменных
http-ответа
Назначение переменных
http-ответа
Назначение переменных
внешних запросах
вебкух
внешнего запроса
допустимые значения
назначение переменных
События
События