Создаём свой BI-дашборд с ИИ-редактором в Битрикс24
Привет! Меня зовут Игорь Росляков, я технический писатель. По приглашению тимлида DevRel-команды Владимира Верхотурова готовлю цикл статей на тему ИИ-ассистированной разработки решений для Битрикс24.
Сегодня создаём приложение для визуализации данных Битрикс24 и настройки собственного BI-дашборда с помощью ИИ. Редактор получает данные из портала и представляет их в удобном виде. Если каких-то возможностей не хватает, их можно будет добавить через агентов. Всё работает внутри экосистемы Битрикс24.
Если хотите сразу скопировать наше решение и попробовать применить его у себя, то вот ссылка на репозиторий:
github.com/igorrosliakov-bitrix24/living-bi-dashboard
Содержание
Как работает наш BI-редактор, где его скачать и как редактировать
Сначала — сам редактор для тех, кому интересно попробовать готовое решение.
AI-редактор BI-отчётов создаёт отдельный дашборд внутри Битрикс24. Он получает агрегированные данные портала: количество сделок, распределение по стадиям или менеджерам, показатели компаний и задач. Карточки CRM в интерфейс не загружаются.
Выглядит это так:
Проект доступен в GitHub: living-bi-dashboard. Сейчас это версия 0.1.0, первый MVP-релиз. Чтобы запустить свою копию, нужно клонировать репозиторий, добавить ключи Вайбкода в .env, выполнить npm ci и npm run dev. Инструкция по подключению к своему порталу и развёртыванию в Галактике есть в README.
Отдельно в проект вшиты инструкции к ИИ-агентам с уточнением всех встреченных ошибок и сложностей при разработке.
Редактировать дашборд можно двумя способами:
В визуальном редакторе пользователь выбирает группировку, направление графика, сортировку, период и палитру, затем сохраняет новую версию. История позволяет вернуться к любой предыдущей конфигурации.
В поле «Команда для ИИ» можно описать правку обычной фразой. Например: «Сделай график по менеджерам горизонтальным и в цветах бренда, KPI-карточки подними наверх». Редактор подготовит
diff: группировку по менеджерам, горизонтальный график и палитру Битрикс24. KPI-карточки уже располагаются над графиками, поэтому эта часть команды закрепляет текущий порядок интерфейса.
Перед применением пользователь видит список изменений и подтверждает их.
Что такое BI-конструктор и BI-отчёт
BI-конструктор в Битрикс24 — встроенный инструмент аналитики. Он берёт данные из портала, например сделки и компании или задачи и сотрудников, и позволяет собрать из них наглядный отчёт.
BI-отчёт — уже готовая страница с показателями и графиками. Здесь можно посмотреть, сколько сделок сейчас в каждой стадии или на какую сумму менеджеры закрыли сделок за квартал.
Как строится работа с этими вещами: внутри BI-конструктора аналитик настраивает, какие данные взять, как их посчитать и как показать. Он может установить, что у сделки нужно взять поле «Стадия», посчитать количество сделок и показать результат столбчатой диаграммой.
Можно добавить фильтры по периоду, менеджеру и направлению продаж. На одном дашборде можно собрать несколько графиков и настроить для них показатели, группировки и оформление.
Есть нюанс: работать с конструктором и отчётами может быть сложно, если вы не аналитик. Чтобы менять отчёт вручную, нужно понимать, какие датасеты и поля существуют, как устроены метрики, группировки и фильтры.
Почему стандартный ИИ-агент не умеет менять BI-отчёты
Для работы с порталом Битрикс24 сейчас есть 2 основных инструмента: ИИ-агент BitrixGPT и платформа Битрикс24 Вайбкод.
Агент отвечает на запросы с помощью уже выданных ему инструментов.
У ИИ нет доступа ко всему Битрикс24. Чтобы что-то сделать, ему нужен конкретный технический способ действия: API-метод или инструмент, например «создать сделку», «получить задачу», «найти сотрудника».
У нативного BI-конструктора Битрикс24 есть интерфейс, где аналитик вручную настраивает датасеты, поля, метрики и графики. Но доступного REST API, через который можно было бы прочитать конфигурацию готового BI-отчёта или изменить его график, фильтр или метрику, пока нет. Зато есть API по датасетам, который мы реализуем отдельно.
ИИ получает список доступных инструментов через протокол MCP. Это работает как набор кнопок, которые разработчик подготовил для агента. Например, ему можно дать инструменты для получения сделок, создания задач или поиска компаний.
Через MCP можно предоставить агенту и инструменты для редактирования BI-отчета — например, update_dataset для обновления датасета или коннектора. Увидев описание такого инструмента, агент поймет, для чего он предназначен и какие параметры нужно передать. При этом сам инструмент должен обращаться к API или другому механизму Битрикс24, который позволяет изменять конфигурацию отчета.
Какой путь даёт Вайбкод-платформа
Нативный BI-конструктор остаётся инструментом аналитика. Но Битрикс24 Вайбкод позволяет создать рядом с ним отдельный дашборд на тех же данных и дать пользователю управляемый ИИ-интерфейс для его настройки.
В нашем проекте это работает примерно так: Вайбкод получает данные портала через API. В данные входят сделки, компании, задачи. Мы храним конфигурацию собственного дашборда в JSON-спеке — структурированном описании виджетов, группировок, фильтров и других параметров дашборда.
Дашборд можно менять указаниями в свободной форме через BitrixGPT. Если пользователь просит отсортировать сделки по возрастанию, BitrixGPT вызывает подготовленные инструменты: читает текущую настройку, проверяет поля и агрегацию. Когда сервер провалидировал изменение, пользователь видит черновик и подтверждает применение. После подтверждения сохраняется новая версия нашего дашборда, которую можно откатить.
А ещё это безопасно, потому что BitrixGPT работает в инфраструктуре Битрикс24, и данные не передаются сторонним LLM-провайдерам. Случайно изменить CRM, задачи или нативный BI-отчёт модель тоже не может: В нашем приложении ИИ получает только действия со спекой дашборда и агрегированными результатами.
Собираем дашборд на платформе Вайбкод
Дальше покажем, как мы собрали наш проект и как он работает. Для работы я использовал ИИ-агента Codex.
Чтобы использовать платформу и связать агента и ваш зарегистрированный портал, понадобится активная подписка BitrixGPT + Маркетплейс. Коробочный Битрикс24 нужно подключить к платформе.
Создаём ключи авторизации
Для подключения приложения к платформе понадобятся ключи доступа. Нужно создать 2 ключа.
API-ключ, чтобы приложение работало от вашего имени:
Ключ для встраивания в портал, чтобы приложение открывалось внутри Битрикс24 — в левом меню, вкладке CRM или виджете.
Для обоих ключей нужно указать скоупы, чтобы ограничить их возможности в портале только необходимыми правами:
Битрикс24:
crm,task+tasks,user,placement,biconnector.vibe:
vibe:ai,vibe:infra,vibe:storage,vibe:search,vibe:feedback.
Создайте в папке проекта файл .env и сохраните ключи в нём. Файл .env добавляют в .gitignore: ключи не попадают в репозиторий, переписку, задачи и скриншоты.
Стандартный промпт к ИИ выглядит примерно так:
Документация: https://vibecode.bitrix24.tech/v1/me
Сделай мне приложение [описание приложения] с авторизацией,
встрой его в Битрикс24 и задеплой на ВайбкодНачинаем создавать дашборд: задаём границы и разделяем задачу на этапы
Создать такой дашборд одним промптом может быть непросто, поэтому лучше описать все требования, попросить составить план из 8-10 пунктов и придерживаться его. Чем точнее будет промпт, тем лучше. Вот наш вариант:
Промпт
Создай production-ready приложение для Битрикс24:
«AI-редактор управленческих дашбордов».
Пользователь открывает приложение внутри своего портала Битрикс24, видит показатели по реальным данным и меняет дашборд обычными фразами.
Приложение сохраняет историю изменений и позволяет отменить любой шаг.
Приложение создаёт собственный дашборд рядом с BI-конструктором
Битрикс24. Оно использует данные того же портала.
Нативные BI-отчёты Битрикс24 не входят в функцию приложения:
публичный REST API не даёт читать и редактировать их конфигурацию.
## Для кого приложение
Для руководителя отдела, собственника, администратора портала и
интегратора, которым нужен понятный управленческий дашборд без
настройки датасетов, SQL и сложной ручной аналитики.
Приложение работает с уже существующими данными портала. Не создавай демо-записи, тестовых сотрудников и seed-скрипты как часть обычного пользовательского сценария.
## Подключение к порталу
Встрой приложение в Битрикс24 через доступный placement Вайбкода.
Сначала проверь GET /v1/placements/available; при отсутствии
BI_ANALYTICS_MENU размести приложение в левом меню.
Используй BFF-архитектуру:
Битрикс24 iframe → Gateway Вайбкода → сервер Галактика/Black Hole →
VibeCode API.
- ключ vibe_app_... хранится только на сервере;
- браузер не получает ключ и пользовательский токен;
- Gateway передаёт серверу сессию текущего пользователя;
- просмотр доступен авторизованным пользователям портала;
- редактирование доступно владельцу дашборда;
- данные не передаются сторонним LLM-провайдерам: BitrixGPT работает в инфраструктуре Битрикс24 и Вайбкода.
## Первый вход и реальные данные
При первом открытии приложение:
1. Получает доступные сущности и их поля через VibeCode API.
2. Предлагает собрать начальный дашборд по сделкам.
3. Показывает понятные названия стадий, сотрудников и отделов.
4. Использует только данные, доступные текущему пользователю.
5. Объясняет пустой результат человеческим текстом:
например, «За текущий квартал сделок не найдено».
Поддержи сделки, компании, задачи, активности и звонки, когда они доступны через entity API.
Показывай только агрегаты и подписи групп. Не передавай в ИИ карточки клиентов, телефоны, e-mail, комментарии и другие сырые персональные данные.
## Возможности дашборда
Поддержи:
- KPI-карточки;
- bar: вертикальный и горизонтальный;
- line;
- pie и donut;
- таблицу;
- общий период дашборда;
- период отдельного виджета;
- фильтры, сортировку, лимиты и группировки;
- палитры, включая палитру Bitrix24;
- кэш агрегатов на 5 минут;
- кнопку «Обновить показатели».
Кнопка «Обновить показатели» заново запрашивает данные портала для сохранённой версии дашборда и обходит кэш. Она не сохраняет изменения, которые пользователь только выбрал в форме.
При изменении визуальных настроек показывай заметную подпись:
«Есть несохранённые изменения. График обновится после сохранения новой версии».
После «Сохранить версию» график обязан перестроиться по новым
настройкам.
## ИИ-редактор
Добавь поле «Команда для ИИ», кнопку подготовки изменения, экран
предпросмотра и кнопку подтверждения.
Используй BitrixGPT через актуальный OpenAI-совместимый endpoint
Вайбкода и function calling.
Разрешённые инструменты модели:
- получить текущую JSON-спеку дашборда;
- получить доступные сущности;
- получить реальные поля выбранной сущности;
- проверить будущую агрегацию;
- подготовить JSON Patch к спеке.
Модель не получает инструментов для записи в CRM, задачах, компаниях или пользователях.
Перед применением изменения модель должна:
1. Получить текущую спеку.
2. Проверить реальные поля портала.
3. Выполнить пробную агрегацию.
4. Подготовить JSON Patch.
5. Показать пользователю короткое описание и понятный diff.
6. Дождаться кнопки «Применить изменение».
Сервер валидирует patch, whitelist сущностей, полей, фильтров,
агрегатов, периодов и типов виджетов. Запрети произвольный код, SQL, HTTP-вызовы и неограниченные выражения.
## Три обязательных сценария
Приложение должно уметь выполнять эти запросы на данных реального портала.
### 1. Визуальное изменение
Команда:
«Сделай график по менеджерам горизонтальным и в цветах бренда,
KPI-карточки подними наверх».
Ожидаемый результат:
- график группируется по менеджерам;
- становится горизонтальным;
- использует палитру Bitrix24;
- KPI-карточки находятся над графиками;
- пользователь видит diff и подтверждает изменение.
### 2. Изменение логики
Команда:
«Конверсию считай только по новым клиентам, исключи воронку "Тест", период -- текущий квартал».
Ожидаемый результат:
- ИИ ищет реальные поля, связанные с типом клиента и воронкой;
- при отсутствии нужного поля задаёт пользователю короткий вопрос выбора, а не придумывает поле;
- создаёт KPI общего количества и успешных сделок;
- считает конверсию как безопасное отношение KPI успешные / все;
- применяет фильтр текущего квартала;
- исключает найденную воронку «Тест».
Поддержи безопасные вычисляемые KPI только в формате отношения
существующих KPI, например:
successful-deals / all-deals
Форматы результата: number и percent. При делении на ноль
показывай 0.
### 3. Новый бизнес-запрос
Команда:
«Добавь виджет: просроченные задачи по отделам и динамика просрочки по неделям».
Ожидаемый результат:
- ИИ находит задачи с просроченным дедлайном;
- получает отдел сотрудника через доступную организационную структуру или маппинг пользователя к отделу;
- добавляет виджет по отделам;
- добавляет line-график с группировкой дат по неделям;
- показывает diff и ждёт подтверждения.
Поддержи безопасную группировку даты по неделе на сервере. Не
передавай модели список задач: в её контекст попадают только доступные поля и агрегированные результаты.
## Версии и отмена
Версионирование является обязательной частью продукта.
- Каждое сохранённое изменение создаёт новую версию JSON-спеки.
- История показывает номер версии, название, автора, время и краткое описание изменения.
- На каждой прошлой версии есть кнопка «Вернуться к версии N».
- Возврат делает выбранную версию текущей и не создаёт копию версии.
- После возврата пользователь сразу видит восстановленный дашборд.
- История хранится в постоянном хранилище Галактики.
- Добавь «Новый дашборд» с подтверждением: он очищает только историю настроек текущего дашборда, данные CRM остаются без изменений.
## Дизайн
Интерфейс должен быть рабочим инструментом, а не демонстрационной страницей.
- В верхней части: название, период, актуальность данных и «Обновить показатели».
- Далее: KPI и виджеты.
- Затем: визуальные настройки и статус несохранённых изменений.
- Ниже: история версий и отмена.
- Рядом или ниже: панель ИИ с черновиком и diff.
- Все кнопки и карточки источников должны быть интерактивными.
- Используй понятные подписи: «Сделки», «Компании», «Задачи», «Звонки». Не показывай пользователю технические пометки вроде MVP, gateway unknown или коды стадий.
## Качество и результат
- Добавь строгую runtime-валидацию входных данных.
- Добавь ESLint, тесты и проверку покрытия не ниже 80%.
- npm run check запускает линтер и тесты.
- npm run audit проверяет уязвимости.
- Добавь README для владельца портала: подключение ключа, установка, деплой, права доступа, ограничения и три готовые команды для ИИ.
- В README явно укажи ограничение агрегаций до 5000 записей и случаи, когда стоит использовать нативный BI-конструктор.
Перед завершением проверь в портале:
1. Приложение открывается через placement.
2. Gateway передаёт пользовательскую сессию.
3. Отчёт строится по реальным данным.
4. Все три команды проходят путь:
фраза → preview → diff → подтверждение → результат.
5. Отмена возвращает любую предыдущую версию.
6. В браузер, логи и контекст ИИ не попадают ключи и сырые персональные
данные.Дополнительно мы попросили агента разделить всю разработку на этапы и отчитываться после каждого шага. ИИ выделил 12 шагов:
Определили задачу
Разобрались, какую проблему решает приложение: руководитель хочет менять отчёт словами, а не осваивать BI-инструменты с нуля.Задали границы
Выбрали отдельный дашборд на данных того же портала.Подготовили проект к работе
Создали репозиторий, настройки, проверки кода и тесты, чтобы проект можно было повторить на другом портале.Подключили Вайбкод
Настроили ключи и серверное приложение, через которое дашборд обращается к данным Битрикс24.Защитили доступ
Настроили Gateway: пользователь открывает приложение внутри портала, а ключи и сессии остаются на сервере.Добавили приложение в Битрикс24
В левом меню портала появился отдельный пункт «AI-редактор BI-отчётов».Научили приложение читать данные
Подключили данные сделок и подготовили каталог доступных сущностей: компаний, задач и активностей. В текущей версии основной дашборд получает агрегаты по сделкам: количества, суммы, группы по стадиям и менеджерам.Собрали первый экран отчёта
Вывели KPI и график по сделкам, добавили понятные названия стадий и кнопку обновления показателей.Сделали визуальную настройку
Пользователь получил возможность менять период, группировку, сортировку, направление графика, палитру и название отчёта.Добавили историю версий
Каждый сохранённый вариант остаётся в истории. Пользователь может вернуться к прошлой версии дашборда одним нажатием.Подключили BitrixGPT
Пользователь пишет запрос обычными словами, модель готовит безопасный черновик изменения, показывает список правок и ждёт подтверждения.Подготовили проект к повторению
Добавили инструкции, тестовые сценарии, проверки кода, нагрузочный набор данных и README, чтобы проект можно было развернуть и проверить на другом портале.
Разработка по шагам помогала отслеживать выполнение проекта и контролировать результат. После завершения этапов мы запускали линтер, тесты и проверку покрытия. Эти проверки помогают заметить регрессию до публикации новой версии.
Когда агент закончил, первая версия выглядела так:
Тут есть сам дашборд, но пока что плохо понятно, как он работает. Самих тестовых данных тоже немного — по скриншоту видно, что в портале всего 38 сделок.
Готовим тестовые данные
На моём тестовом портале почти не было сделок и задач. В такой ситуации дашборд технически работает, но графики остаются пустыми. Для демонстрации мне был нужен небольшой набор записей с понятной структурой: несколько компаний, сделки на разных стадиях и задачи с будущими и просроченными сроками.
Я попросил ИИ-агента подготовить seed-скрипт. Он содержит команды для API: создать компании, сделки и задачи. Сначала я попросил агента написать этот файл, затем мы запустили его командой npm run seed:
Подготовь один seed-скрипт для тестового портала Битрикс24.
Команда запуска:
npm run seed:bi-lab -- --manager-ids=30,32,34,36,38 --confirm
Скрипт через VibeCode batch API должен создать записи с префиксом
VIBECODE_BI_LAB:
- 20 компаний;
- 2 000 сделок, распределённых между менеджерами из параметра;
- сделки на стадиях «Новая», «Подготовка документов», «Успех» и
«Провал»;
- часть сделок за последние 6-12 месяцев и минимум 400 за текущий квартал;
- тестовую воронку «Тест», если её создание поддерживает API;
- 100 задач с дедлайнами за последние 8 недель, включая просроченные.
Набор должен позволить проверить: график по менеджерам, конверсию новых клиентов
за текущий квартал с исключением тестовой воронки и просроченные задачи по отделам
с динамикой по неделям.
Перед запуском проверяй записи с этим префиксом и останавливайся при повторном
запуске. Сотрудников не создавай и существующие записи не меняй. Добавь тесты,
README и финальный вывод с количеством созданных записей.Если вы подключаете приложение к рабочему порталу с уже заполненными CRM и задачами, seed-скрипт вам не нужен. Переходите сразу к созданию дашборда на своих данных.
Агент изучил доступные поля портала и добавил в проект файл scripts/seed-demo-data.js. В нём агент разбил операции создания записей на batch-пакеты. Скрипт использовал Batch API и отправлял команды пакетами. Это уменьшило количество отдельных обращений к API и помогло уложиться в лимиты платформы.
Теперь у дашборда появился материал для работы: он может посчитать количество сделок, разложить их по стадиям и проверить фильтры по периоду. Данные задач пригодятся для отдельного виджета просроченных задач.
Сложности во время создания дашборда
Даже с детальным промптом и разделением разработки на этапы на создание работающего BI-дашборда и исправление ошибок ушло какое-то время. После окончания работы я попросил агента проанализировать все наши ошибки и составить рекомендации, которые помогут быстрее реализовать похожий проект.
Вот что посоветовал агент:
Сначала проверить интеграцию, потом строить интерфейс: placement, Gateway, URL в Галактике, сервер и пользовательская сессия.
Сделать один «живой» запрос к данным портала в первый день: например, получить 10 сделок. Это сразу показывает, работает ли доступ.
Сразу выбрать постоянное хранилище для конфигураций и версий. Иначе после перезапуска пропадут настройки и история.
Добавить тестовые данные до разработки графиков: несколько менеджеров, сделки в разных стадиях, задачи, компании. Для проверки скорости подготовить отдельный набор на 1–2 тыс. сделок.
Сначала реализовать один законченный сценарий: данные портала → график → сохранение версии → восстановление. После него расширять дашборд.
Описать конфигурацию дашборда в строгой схеме: какие есть виджеты, группировки, периоды, палитры и фильтры. Тогда интерфейс и ИИ работают с одними правилами.
Ограничить ИИ разрешёнными операциями и полями: add, replace, remove по заранее известным путям. Перед применением всегда показывать diff.
Разделить запросы на два типа: доступные настройки меняются сразу, а новый функционал превращается в структурированную заявку для агента разработки.
После каждого изменения проверять сценарий внутри Bitrix24, а не только по локальному адресу. Именно портал передаёт Gateway-сессию.
Вести короткий PROGRESS.md: текущий этап, работающие сценарии, известные ограничения, адреса и команды запуска. Это особенно спасает после пауз и при передаче проекта другому разработчику.
Меняем параметры и версии дашборда
После запуска seed-скрипта данных стало больше. Теперь с ними можно работать и ставить эксперименты:
Сразу под графиком находятся его параметры. Их можно менять и сохранять новую версию конфигурации дашборда. К любой сохранённой версии можно вернуться:
Первый сценарий кастомизации дашборда через ИИ
Теперь попробуем кастомизировать внешний вид отчёта через нейросеть.
Сначала поменяем график и сделаем так, чтобы видеть количество сделок у каждого менеджера:
Внизу редактора есть специальное поле, куда можно записывать запрос к агенту:
Попробуем попросить поменять тип графика и внести ещё парочку небольших изменений:
Сделай график по менеджерам горизонтальным и в цветах бренда,
KPI-карточки подними наверхПо нашему сценарию внутренний агент сначала должен подготовить изменения и объяснить их пользователю. В первых версиях редактора это работало с перебоями — агент выдавал малопонятную ошибку:
После нескольких итераций исправлений агент довёл эту часть до работающего состояния. Теперь в редакторе видны будущие изменения, которые можно принять:
Новый внешний вид отчёта сохраняется в новую версию и автоматически применяется:
Кто на самом деле меняет дашборд
На предыдущем этапе мы пропустили объяснение важной детали.
BitrixGPT меняет только те настройки, для которых разработчики уже добавили инструменты и правила проверки. MCP передаёт агенту этот набор инструментов. Новая функция появляется после доработки исходного кода приложения.
Поэтому для новой возможности мы передали структурированную заявку внешнему агенту разработки Codex. Он дорабатывает исходный код приложения: добавляет виджеты, фильтры, расчёты и правила валидации, затем запускает тесты и публикует новую версию. После /публикации BitrixGPT получает возможность работать с добавленной функцией.
Делаем кастомизации дашборда через ИИ повторяемыми
Чтобы упростить добавление новых функций, мы научили редактор распознавать запросы, которые выходят за рамки его текущих возможностей. В таком случае BitrixGPT объясняет, чего не хватает, и формирует описание задачи для внешнего агента разработки:
Это объяснение можно скопировать и переслать внешнему агенту, который работает с вашим порталом:
После этого кастомизация становится возможной:
Теперь можно применить изменения и получить новый отчёт:
Публикуем данные в нативный BI-конструктор
Наш AI-редактор строит собственный дашборд внутри Битрикс24 и меняет его настройки по команде пользователя. Но у Битрикс24 есть REST API для ещё одной задачи: через методы biconnector.*. приложение может создавать и обновлять датасеты для нативного BI-конструктора.
Датасет представляет собой подготовленную таблицу данных. Например, для компании по производству окон в неё можно передавать номер заказа, менеджера, сумму. После публикации таблица появляется в «Рабочем месте аналитика», где аналитик собирает нативные графики Битрикс24.
Мы добавили в проект отдельный адаптер-сервис для BI-коннектора. Он отвечает на запросы BI-конструктора: передаёт список таблиц, описание их полей и строки данных. Для проверки мы создали через API-коннектор, источник и датасет. После этого открыли датасет в BI-конструкторе и собрали нативный отчёт-таблицу. В нём появились три демонстрационные сделки с суммами и датами:
Сначала BI-конструктор получает строки датасета в редакторе графика. Затем аналитик размещает созданный виджет на обычном нативном дашборде.
Итоговая схема приложения работает так:
Наше приложение →
adapter →
BI-коннектор →
источник →
датасет →
нативный отчёт Битрикс24
Этот путь расширяет возможности проекта:
AI-редактор помогает руководителю быстро настраивать собственный рабочий дашборд: например, вывести сделки по менеджерам, включить текущий квартал и сохранить новую версию.
Публикация датасетов даёт аналитику данные для штатного BI-конструктора, где можно собрать более сложные отчёты из CRM, ERP и производственных систем.
Сейчас проверочный контур уже работает: API создаёт датасет, BI-конструктор видит его и получает строки через adapter. Для постоянной работы с реальными данными стоит решить две инфраструктурные задачи: дать адаптер-серверу стабильный публичный HTTPS-адрес и настроить OAuth локального приложения Битрикс24.
После этого можно будет добавить в интерфейс приложения управляемый сценарий через кнопки: «Опубликовать датасет», «Обновить данные», «Посмотреть время последней синхронизации» и «Удалить тестовый источник».
Что ещё можно оптимизировать в нашем редакторе
Текущая версия уже работает и может приносить пользу, но имеет ограничения. Основной дашборд строится по сделкам, а карточки компаний, активностей и задач в левой панели служат каталогом данных для будущих виджетов. Запросы, требующие новой бизнес-логики или нового виджета, приложение превращает в структурированную заявку для агента разработки.
Чтобы внести изменения, скопируйте проект себе, протестируйте на своих данных и напишите первый запрос на изменение:
github.com/igorrosliakov-bitrix24/living-bi-dashboard