Привет! Меня зовут Игорь Росляков, я технический писатель. По приглашению тимлида DevRel-команды Владимира Верхотурова готовлю цикл статей на тему ИИ-ассистированной разработки решений для Битрикс24.
В прошлой статье мы построили AI-редактор BI-отчётов: отдельный дашборд внутри Битрикс24, который меняется по фразе пользователя.
Сегодня разбираем другую половину задачи. У аналитика в BI-конструкторе две работы: сначала он собирает данные для отчётов, потом собирает сам отчёт с графиками. API Битрикс24 может автоматизировать первую половину. Значит, её можно отдать ИИ, а человеку оставить визуализацию. Расскажем, как мы это сделали и какие были сложности.
Если хотите сразу скопировать наше решение и попробовать применить у себя, то вот ссылка на репозиторий:
github.com/igorrosliakov-bitrix24/living-bi-dashboard
Содержание
Что сделаем в этой статье
Первая статья отвечала на вопрос «как дать руководителю менять отчёт словами». Приложение читает агрегаты портала, рисует собственный дашборд и позволяет менять его настройки обычной фразой.
Вторая статья отвечает на другой вопрос: как отдать аналитику готовый расчётный набор данных, которого в Битрикс24 ещё нет.
Идея простая. Что делает аналитик в нативном BI:
Сначала собирает данные — решает, какие поля взять, как их посчитать, откуда достать.
Потом собирает отчёт — выбирает график, оси, фильтры, раскладку.
Мы автоматизируем первую половину: пользователь описывает нужный набор словами, приложение формирует его и публикует в «Рабочее место аналитика». Дальше человек один раз собирает график, и набор живёт своей жизнью — с некоторыми нюансами.
Получается честное разделение труда. ИИ делает скучную половину, человек — наглядную. Графиков наш ИИ пока не рисует.
В новой статье мы построили 3 части.
1 — Адаптер с четырьмя точками входа, который отвечает BI-конструктору Битрикс24 и считает строки по живой CRM.
BI-конструктор Битрикс24 умеет подключаться к внешним источникам данных. Для этого в нём заводят запись, которая говорит: «данные лежат вон по тем четырём адресам». Но есть важное условие: Битрикс24 не принимает данные, он приходит за ними сам. Портал сервер-к-серверу дёргает наши URL и задаёт четыре вопроса:
Маршрут |
Что спрашивает Битрикс24 |
/bi-connector/check |
Ты живой? |
/bi-connector/tables |
Какие таблицы у тебя есть? |
/bi-connector/table-description |
Какие колонки в этой таблице и какого типа? |
/bi-connector/data |
Дай строки. |
Отвечать на них — и есть работа адаптера уже в нашем приложении. Это обычный Node.js-сервис, который считает строки по CRM в момент запроса. А ещё отсюда требование публичного HTTPS: портал должен до нас достучаться, localhost ему недоступен.
2 — Публикатор, который превращает фразу от пользователя в проверенную спецификацию датасета и создаёт его через REST.
3 — Управляемый контур с кнопками:
опубликовать набор;
обновить данные;
проверить синхронизацию;
удалить.
Итоговая схема:
фраза пользователя → спецификация → Dataset API → адаптер → нативный график
Как работает наше приложение, где его скачать и как редактировать
Сначала — сам редактор для тех, кому интересно попробовать готовое решение.
Проект доступен на GitHub: living-bi-dashboard. Сейчас это версия 0.2.0. Чтобы запустить свою копию, клонируйте репозиторий, добавьте ключи Вайбкода в .env, выполните npm ci и npm run dev. Инструкция по подключению к своему порталу и развёртыванию есть в README.
Приложение из этой статьи состоит из двух сервисов. Интерфейс работает внутри портала и показывает дашборд. Адаптер-сервис отвечает BI-конструктору Битрикс24 и считает строки по данным портала. Развернуть их нужно на отдельные машины: интерфейс открывается только через портал, а к адаптеру Битрикс24 обращается напрямую.
Отдельно в проект вшиты инструкции к ИИ-агентам с уточнением всех встреченных ошибок и сложностей при разработке.
Работать с приложением можно двумя способами.
Настроить собственный дашборд. Эту часть мы сделали в прошлой статье. В визуальном редакторе пользователь выбирает группировку, направление графика, сортировку, период и палитру, затем сохраняет новую версию. В поле «Команда для ИИ» ту же правку можно описать фразой: «сделай график по менеджерам горизонтальным и в цветах бренда». Редактор готовит diff, пользователь подтверждает изменения. История позволяет вернуться к любой предыдущей конфигурации.
Подготовить набор данных для BI-конструктора. Это новая часть. В блоке «Подготовить набор данных» пользователь описывает нужные показатели обычной фразой, например «конверсия по менеджерам за текущий месяц». Приложение показывает, что получится: имя набора, поля с типами, период и формулу расчёта. После подтверждения оно публикует набор в «Рабочее место аналитика», где аналитик собирает по нему график.
Отдельно в проект вшиты инструкции к ИИ-агентам с уточнением всех встреченных ошибок и сложностей при разработке.
Что такое BI-конструктор и BI-отчёт
BI-конструктор в Битрикс24 — встроенный инструмент аналитики. Он берёт данные из портала, например сделки и компании или задачи и сотрудников, и позволяет собрать из них наглядный отчёт.
BI-отчёт — уже готовая страница с показателями и графиками. Здесь можно посмотреть, сколько сделок сейчас в каждой стадии или на какую сумму менеджеры закрыли сделок за квартал.
Как строится работа с этими вещами: внутри BI-конструктора аналитик настраивает, какие данные взять, как их посчитать и как показать. Он может установить, что у сделки нужно взять поле «Стадия», посчитать количество сделок и показать результат столбчатой диаграммой.
Можно добавить фильтры по периоду, менеджеру и направлению продаж. На одном дашборде можно собрать несколько графиков и настроить для них показатели, группировки и оформление.
Есть нюанс: работать с конструктором и отчётами может быть сложно, если вы не аналитик. Чтобы менять отчёт вручную, нужно понимать, какие датасеты и поля существуют, как устроены метрики, группировки и фильтры.
Проходим сценарий работы по шагам
Объяснения без иллюстраций могут запутать, поэтому лучше покажем по шагам, как работает новый ИИ-редактор с датасетами и какой от этого толк.
Мы рассчитываем, что этот сценарий вы проходите, когда приложение установлено и задеплоено.
Шаг 1. Открываем приложение в левом меню портала и находим блок AI Dataset Publisher.
Чаще всего приложение-кастомизацию включают здесь:
Открываем приложение и прокручиваем вниз — та часть, которая называется AI DATASET PUBLISHER, и есть наше обновление.
Шаг 2. Выбираем, куда применить запрос — создать новый набор или изменить один из уже опубликованных
Можно создать новый датасет или изменить существующий:
Шаг 3. Описываем нужные данные обычной фразой
Приложение не даёт модели полной свободы. BitrixGPT выбирает ключи из каталога, который заранее объявил разработчик, то есть мы. Всё остальное строит сервер и перепроверяет после модели.
Поэтому, например, «добавь конверсию» работает, а «выручка по товарам» — нет. Первое есть в каталоге, второго нет. Расширить каталог может только разработчик. Зато после этого новая метрика становится доступна всем пользователям обычной фразой.
Создаём новый датасет:
Шаг 4. Проверяем preview
Приложение показывает техническое имя набора, список полей с типами, период, фильтры и формулу расчёта. В Битрикс24 на этом шаге ничего не создаётся.
Шаг 5. Подтверждаем черновик.
Черновик живёт внутри приложения, портал по-прежнему не тронут.
Шаг 6. Смотрим план публикации
Приложение сравнивает схему с Битрикс24 и говорит прямо, что действие создаст новый набор, добавит совместимые поля или предложит новую версию. Для несовместимых изменений при работе с уже существующим датасетом оно создаёт _v2 и оставляет исходный набор нетронутым.
Шаг 7. Публикуем
На этом шаге впервые появляется объект в портале.
Появится всплывающее окно с именем нового датасета и запросом подтверждения:
Шаг 8. Аналитик открывает таблицу в «Рабочем месте аналитика» и видит реальные строки, которые адаптер посчитал по живой CRM
Открываем раздел BI Конструктор и заходим в «Рабочее место аналитика»:
Дальше можно найти новый датасет:
Датасет можно открыть и посмотреть данные внутри. Обратите внимание, что в этой форме есть кнопка «Синхронизировать с источником» — она критически важна для сегодняшней темы:
Шаг 9. Собираем график
График нужно собрать один раз самостоятельно.
Возвращаемся в BI Конструктор и создаём новый отчёт:
Задаём название и указываем, где он будет храниться:
После этого, если нажать «Сохранить», откроется новое окно:
Нажимаем на 3 точки справа вверху и выбираем «Редактировать отчёт»:
После этого — «Редактировать дашборд»:
Дальше — «Создать новый график»:
В новом окне выбираем только что созданный датасет и подходящий тип диаграммы:
Расставляем поля из датасета по подходящим параметрам графика:
И получаем сам график:
Шаг 10. Как обновляются данные
Между CRM и графиком стоят два хранилища, и каждое обновляется по своему правилу.
Первое — кэш адаптера. Он живёт один час и нужен, чтобы не дёргать CRM на каждый запрос портала, потому что данных может быть очень много. Когда кэш истекает, следующий запрос адаптер обслуживает свежим расчётом. Кнопка «Обновить данные сейчас» сбрасывает кэш немедленно. Это звено приложение контролирует полностью: набор всегда готов отдать актуальные цифры.
Второе — копия строк на стороне Битрикс24. Именно её читает график, и обновляется она, когда аналитик открывает таблицу и нажимает «Синхронизировать с источником» — эта часть из следующего, 11-го шага.
Состав полей ведёт себя иначе. Новая колонка появляется в таблице сама, без синхронизации. API управляет схемой полноценно, а момент забора данных выбирает портал.
Шаг 11. Аналитик синхронизирует таблицу с источником
Чтобы график увидел новые цифры, остаётся ручной шаг: нажать на кнопку синхронизации в датасете:
Для примера мы увеличим количество сделок одного из менеджеров портала — Варвары Беловой.
На нашем готовом графике есть показатели по сделкам. В графике кастомного приложения отражаются все сделки:
А в графике созданного нами нативного BI-конструктора — только сделки за определённый период времени:
Для эксперимента я попросил агента добавить менеджеру 15 сделок, обновил данные через синхронизацию в таблице и проверил, что показывают обновлённые графики:
Шаг 12. Просим добавить поле новой фразой
Приложение показывает diff, добавляет колонку к существующему набору и не ломает уже собранный график.
В примере мы берём существующий датасет и просим добавить конверсию.
BitrixGPT читает требования, готовит изменения и показывает, что он добавит новое поле — CONVERSION_PERCENT:
Теперь это поле можно увидеть в самом датасете:
И при редактировании графика:
Шаг 13. Удаляем датасет и связанные с ним таблицы
Что для этого нужно: зайти в «Рабочее место аналитика» → удалить датасет → удалить таблицу. Порядок обязателен.
Сначала удаляем датасет:
После этого можно удалить связанную с ним таблицу:
Что делают кнопки в блоке «Синхронизация»
В приложении есть ещё две кнопки, на которых остановимся отдельно.
Кнопка Проверить синхронизацию узнаёт, ходит ли портал за данными. Действие ничего не меняет, только спрашивает. Дашборд стучится к адаптеру и показывает две вещи: когда BI-конструктор последний раз успешно забрал данные и сколько раз он обращался с момента запуска. На нашем скриншоте — 25.08.2026, 01:17:46, 83 запроса.
Это помогает ответить на вопрос: «канал жив?» Если после публикации график пустой, эта кнопка сразу говорит, в чём дело. Если там ноль обращений — то портал вообще ещё не приходил, проблема на стороне подключения. А когда обращения есть, а график пуст, портал приходил и получил пустой ответ. Тогда проблема в данных или в реестре.
Обновить данные сейчас — означает заставить адаптер пересчитать данные немедленно. Это уже действие. Адаптер держит результат в кэше один час, чтобы не гонять CRM на каждый запрос. Кнопка сбрасывает кэш и пересчитывает набор из CRM прямо сейчас, а в ответ показывает, сколько строк получилось и во сколько.
Это может выглядеть как указание: «я только что поменял сделки — пересчитай».
Четыре объекта, которые заводятся в портале
Чтобы аналитик увидел таблицу, в Битрикс24 появляются четыре связанных объекта. Их создаёт приложение через методы biconnector.*.
Коннектор описывает, как портал будет разговаривать с внешним сервисом. Здесь лежат те самые четыре адреса, название и иконка. Коннектор заводится один раз.
Источник — конкретное подключение по этому коннектору. Он ссылается на коннектор и служит владельцем таблиц. Тоже заводится один раз.
Датасет — одна таблица, которую увидит аналитик. У него есть техническое имя, человеческое название и список полей с типами. Датасетов может быть сколько угодно, и все они принадлежат одному источнику.
В нашем прогоне это выглядело так: коннектор «VibeCode AI Dataset Connector», источник «VibeCode AI Dataset Source» и три датасета внутри него.
Приложение делает это само. При первой публикации оно находит коннектор и источник или создаёт их, дальше добавляет только датасеты.Четвёртый объект — таблица. Её портал создаёт сам, когда появляется датасет. Именно таблицу вы открываете в разделе «Таблицы» и по ней строите график. Помнить о ней стоит в одном случае: убирая набор, сначала удаляют датасет, потом таблицу.
Что модель отдаёт вместо текста
BitrixGPT в нашем приложении не пишет ни текста, ни кода. Он заполняет анкету с фиксированными полями, и в каждое поле можно вписать только значение из заранее объявленного списка. Заполненную анкету мы называем спецификацией.
Выглядит она так:
{ "dimensions": ["manager"], "metrics": ["total_deals", "won_deals"], "period": "current_month", "filters": {}, "title": "Сделки и выигрыши по менеджерам" }
Пять полей, и в трёх из них — только ключи из каталога. Имён полей CRM здесь нет, SQL нет, параметров REST нет. Всё это сервер достраивает сам: из ключа manager он разворачивает колонки MANAGER_ID и MANAGER_NAME, из total_deals — колонку TOTAL_DEALS целого типа и правило её расчёта.
Отсюда и главное свойство решения. Ошибка модели не превращается в неконтролируемый запрос к данным. Максимум, что она может сделать неправильно, — выбрать не тот ключ из списка, и это будет видно в preview до публикации.
Где адаптер помнит про наборы
Битрикс24 спрашивает адаптер: «Какие у тебя есть таблицы?» и «Дай строки для такой-то таблицы». Значит, адаптер должен знать, какие наборы существуют и как считать каждый из них.
Для этого он держит реестр — файл, в котором на каждый опубликованный набор лежит его спецификация и состояние. Реестр живёт на постоянном диске за пределами каталога приложения, поэтому переживает выкладку новой версии.
Состояний три:
pending— набор готовится к публикации.active— набор опубликован и обслуживается.failed— публикация не удалась.
Пока запись активна, адаптер отдаёт по ней данные. Если реестр и портал разойдутся, аналитик увидит пустую таблицу при живом датасете, поэтому приложение приводит их в согласие при каждой публикации.
Проходим и объясняем промпты для повторения второй части проекта
Промпты не могут дать гарантию такого же результата, поэтому после каждого шага я советую проверять результат руками и глазами. Если что-то не сходится — это сразу стоит чинить. Проверку агент напишет сам, а вы её читаете и решаете: идти дальше или переделать шаг.
Порядок важен. Первые два шага дают контур, в котором Битрикс24 вообще может с вами разговаривать. Остальные пять добавляют безопасность и умения.
Шаг 1. Адаптер с четырьмя точками входа
Начинаем с адаптера — сервиса, которому Битрикс24 задаёт свои четыре вопроса. Пока без CRM и без ИИ, на заглушках: сначала надо убедиться, что портал вообще с нами разговаривает.
Сделай Node.js-сервис adapter-server.js без внешних зависимостей. Он отвечает BI-коннектору Битрикс24 на четыре POST-маршрута: /bi-connector/check, /bi-connector/tables, /bi-connector/table-description, /bi-connector/data. Битрикс24 шлёт тело в формате form-urlencoded с индексами вида fields[0]. Разбери его в объект. Добавь GET /health, который отдаёт JSON со статусом сервиса. Не отдавай HTML ни на одном маршруте: Битрикс24 ждёт только JSON. Пока верни на всех четырёх маршрутах одну тестовую таблицу с тремя строками и полями ID, TITLE, AMOUNT. Добавь юнит-тесты на разбор тела запроса и на форму ответа. В конце покажи: какие четыре URL я должен указать при создании коннектора и что вернёт каждый из них.
Проверить руками получится только частично. Запустите сервис локально и вызовите /health из браузера. Остальные маршруты Битрикс24 будет дёргать сам, после следующего шага.
Шаг 2. Публичный адрес и OAuth локального приложения
Без публичного HTTPS Битрикс24 до вас не достучится, а без OAuth не пустит к методам biconnector.*. Этот промпт закрывает обе задачи.
Выложи adapter-server.js на отдельный сервер с постоянным HTTPS-адресом и политикой доступа PUBLIC. Автоматическое засыпание выключи. Добавь маршрут POST /bitrix/install: локальное приложение Битрикс24 пришлёт туда токены после установки. Проверяй секрет установки из переменной окружения, чужой запрос отклоняй. Храни OAuth-состояние в файле за пределами каталога приложения, чтобы оно пережило выкладку. Шифруй файл ключом из окружения. Реализуй автоматическое обновление access-токена по refresh-токену. /health должен показывать, настроен ли OAuth и зашифровано ли хранилище, но не показывать сами значения. В конце покажи: какие поля я должен заполнить в карточке локального приложения и как убедиться, что токены сохранились.
Проверить руками легко. Откройте /health по публичному адресу — он должен вернуть JSON с признаком настроенного OAuth. Затем создайте коннектор в BI-конструкторе и убедитесь, что портал видит вашу тестовую таблицу.
Шаг 3. Каталог возможностей
Здесь появляется главная защита. Модель не должна выдумывать поля CRM и писать запросы к данным. Она выбирает ключи из списка, который вы объявили заранее.
Сделай каталог возможностей публикатора в одном файле. Опиши измерения, метрики и периоды. Для каждого измерения — какие поля датасета оно даёт и как разложить сделку по этим полям. Для каждой метрики — код поля, тип, человеческая формула и функция расчёта. Для каждого периода — как посчитать его границы. Начни с трёх измерений (неделя, менеджер, воронка), трёх метрик (всего сделок, выигранные сделки, конверсия) и трёх периодов (месяц, квартал, год). Сущность только одна: сделки CRM. Сделай каталог единственным источником правды. Ни один другой файл не должен повторять эти списки: всё остальное строится из каталога. Добавь проверку спецификации: разрешены только ключи каталога, дубликаты запрещены, нужно хотя бы одно измерение и одна метрика, имя датасета формирует сервер. Добавь тест, который падает, если список ключей продублируют где-то ещё. В конце покажи: что нужно поправить, чтобы добавить новую метрику.
Руками это не проверить, но проверяется тестом. Правильный ответ агента на последний пункт — «только каталог». Если он перечислит несколько файлов, шаг придётся переделать. Я на этом потерял много времени: список жил в трёх местах, и добавление метрики требовало четырёх согласованных правок.
Шаг 4. Движок расчёта по сделкам
Теперь адаптер должен считать настоящие данные вместо заглушки.
Замени тестовую таблицу расчётом по CRM портала. По спецификации из каталога: определи набор нужных полей сделки, загрузи сделки за период с пагинацией, примени фильтры по воронкам, сгруппируй по выбранным измерениям и посчитай метрики. Фильтр воронок сравнивай без учёта регистра. Неизвестное название воронки — ошибка с понятным текстом, а не молчаливое игнорирование. Ограничь выборку разумным числом сделок и дай понятную ошибку при превышении. Добавь кэш результата на несколько минут. Никаких карточек клиентов и персональных данных в выдаче: только агрегаты. Добавь тесты на группировку, конверсию при нулевом знаменателе и исключение воронок. В конце покажи: сколько сделок попало в расчёт и сколько строк получилось на выходе.
Как проверить руками: откройте таблицу в «Рабочем месте аналитика» — предпросмотр покажет реальные строки из вашей CRM.
Шаг 5. Планировщик на BitrixGPT
Здесь появляется ИИ. Обратите внимание: модель получает ровно два инструмента и не получает права выполнять запросы.
Добавь маршрут, который превращает фразу пользователя в проверенную спецификацию датасета. Модель вызывает один из двух инструментов: подготовить спецификацию или объяснить, почему запрос выходит за возможности каталога. Списки разрешённых ключей и текст системного промпта строй из каталога, а не пиши руками. Сервер обязан перепроверить ответ модели по каталогу. SQL, код, имена полей CRM и произвольные параметры REST не принимай. Ответ пользователю показывай как preview: имя набора, поля с типами, период с реальными датами, фильтры и формулу расчёта. В Битрикс24 на этом шаге ничего не создавай. Добавь тесты на корректный вызов инструмента, на отказ и на попытку подсунуть поле вне каталога. В конце покажи: три фразы, которые дают разные спецификации, и одну, которая уходит в заявку на доработку.
Для проверки отправьте запрос про выручку по товарам — приложение обязано отказать и объяснить, чего не хватает. Портал при этом остаётся нетронутым, что видно в списке датасетов.
Шаг 6. Публикация с diff и версионированием
Самый ответственный шаг: здесь приложение впервые меняет портал.
Добавь публикацию датасета через методы biconnector. Перед изменением сравни схему с Битрикс24 и покажи план: что добавить, что удалить, где меняется тип. Добавление полей выполняй как совместимое изменение. Удаление поля или смену типа не применяй к существующему набору: создавай новую версию с суффиксом _v2 и оставляй исходный набор нетронутым. Публикация должна быть идемпотентной. Если схема уже совпадает, не делай ни одного вызова к Битрикс24. Если вызов упал, верни реестр к предыдущей рабочей версии. Никогда не оставляй в сломанном состоянии набор, который работал до этой операции. Сохраняй настоящий код ошибки Битрикс24, а не свой обобщённый. Создавай только объекты с префиксом vibecode_ai_ и проверяй принадлежность перед любым изменением. Добавь тесты: повтор без изменений не делает вызовов, неудачное обновление возвращает прежнюю версию, несовместимое изменение предлагает _v2. В конце покажи: что произойдёт, если нажать «Опубликовать» дважды.
Обязательно проверить руками. Опубликуйте набор, откройте список датасетов в BI-конструкторе и убедитесь, что появился ровно один объект. Затем нажмите «Опубликовать» ещё раз — дубликата быть не должно. В моём случае повторная публикация ломала работающий набор, и график молча пустел.
Шаг 7. Интерфейс с четырьмя кнопками
Последний шаг собирает всё в экран, которым пользуется человек.
Добавь в интерфейс приложения блок публикации наборов данных. Поля: выбор между новым набором и уже опубликованным, текст запроса, кнопка подготовки. Дальше preview, подтверждение черновика и план публикации. Кнопки: опубликовать набор, проверить синхронизацию, обновить данные сейчас, удалить набор. После перезагрузки страницы управление опубликованным набором должно оставаться доступным: восстанавливай спецификацию из хранилища, без обращения к модели. Ошибки платформы показывай их настоящим текстом. Сбой сервера или истёкшая сессия не должны выглядеть как ошибка модели. Одна неудачная операция не должна ронять приложение: обрабатывай отказы всех маршрутов. В конце покажи: что увидит пользователь, если сессия истекла и он нажал кнопку публикации.
Проверок две.
Первая — про сохранение состояния. Перезагрузите страницу и выберите уже опубликованный набор. Панель управления обязана открыться сразу, из сохранённой спецификации, без нового обращения к модели.
Вторая — про текст ошибки. Приложение открывается из меню портала, и в этот момент Gateway передаёт ему сессию пользователя. Живёт она полчаса и хранится в памяти сервиса, поэтому пропадает ещё и при выкладке новой версии. Это и есть удобный способ проверки: выложите приложение заново и, не перезагружая вкладку, нажмите любую кнопку.
Дальше смотрим, кто что говорит. Сервер обязан ответить настоящей причиной: сессии нет, откройте приложение через Битрикс24 заново. Интерфейс обязан показать этот текст как есть. Пользователь по нему понимает, что делать, — переоткрыть приложение из меню.
Неправильное поведение выглядит так: на экране «ИИ не смог подготовить черновик». Интерфейс поймал отказ сервера и подписал его своей догадкой про модель. Мы на этом тоже потеряли время — искали проблему в промпте, а на самом деле истекла сессия.
Что ещё можно оптимизировать в нашем редакторе
Текущая версия считает одну сущность — сделки CRM: три измерения, три метрики, три периода. Всё это лежит в каталоге возможностей, поэтому новый показатель добавляется правкой одного файла.
Но есть и недостатки, которые мы собираемся закрыть. Например, имя набора не учитывает период. Оно собирается из метрики и измерения, так что запрос за месяц и за квартал дают одно имя, и второй переиспользует первый набор вместо нового. А ещё годовой период упирается в потолок выборки. Нужна агрегация на стороне CRM.
Чтобы внести изменения и попробовать, как всё работает сейчас, скопируйте проект, протестируйте на своих данных и напишите запрос на изменение: github.com/igorrosliakov-bitrix24/living-bi-dashboard