Михаил Лабеев
Аналитик, департамент CRM&BPM, «КОРУС Консалтинг»
Привет, Хабр! Меня зовут Михаил Лабеев, я аналитик в департаменте CRM&BPM «КОРУС Консалтинг». В статье расскажу о том, как мы закрыли типовые запросы бизнеса на отображение связанных данных, цветовую подсветку и видимость полей силами системного администратора.
Введение: Вечный цикл «доработай карточку»
Если вы администрируете или настраиваете систему на базе BPMSoft, вам точно знакомы похожие сценарии.
Подходит руководитель отдела продаж и говорит: «В карточке лида мне нужно видеть сумму последнего успешного договора, и если она больше миллиона, пусть подсвечивается зеленым».
Или пишет начальник службы поддержки: «А можно, чтобы в обращении клиента поле "Срочность" показывалось только старшим инженерам?».
Каждый такой запрос — это мини-проект. Нужно подготовить ТЗ, привлечь разработчика, внести правки в конфигурацию, обновить систему, протестировать изменения — все это очень трудозатратно.
В ходе эксплуатации системы таких запросов появляется множество, а приоритет их реализации, как правило, низкий. Потому что параллельно с такими задачами приходится обрабатывать запросы на изменение самой логики работы, фиксить баги — в общем, уделять внимание более критичным задачам. В результате простые, но важные для пользователей правки копятся в очереди.
Поэтому мы решили разработать инструмент, которым может пользоваться системный администратор системы, чтобы без привлечения разработчиком вносить необходимые изменения в карточку. Так родилось наше внутреннее RND-решение «Управление виртуальными полями». Его цель — позволить админу самостоятельно через интерфейс решать около 30% типовых задач по доработке внешнего вида и логики отображения карточек.
Что скрывается за термином «Виртуальное поле»?
В рамках нашего решения мы дали четкое определение: Виртуальное поле — это поле, которое не хранит данные в БД системы, но может отображать на карточке информацию, полученную из связанных таблиц (разделов).
Проще говоря, это «окно» или «линза» в другие данные. Оно не создает новые атрибуты сущности, а лишь показывает существующие в нужном контексте.
Аналогия из Excel: Представьте столбец Итог, в ячейке которого формула =СУММ(A2:C2). Сам столбец Итог данных не хранит — он вычисляет их на лету. Наше виртуальное поле работает похожим образом.
Ключевая ценность в том, что мы отделили представление данных от хранения данных. Это дает невероятную гибкость для адаптации интерфейса под нужды конкретных бизнес-ролей без риска поломать логику процессов или целостность данных.
Архитектура: Как это устроено под капотом?
Мы внедрили это решение в интерфейс платформы, никак не меняя логику ее работы.
Создается виртуальное поле из любого раздела карточки с помощью специально разработанного интерфейса: администратор выбирает источник данных, место отображения и задает правила видимости или цветового форматирования, выбирает, какие пользователи могут видеть поле, а какие нет.
Все созданные администратором виртуальные поля раздела отображаются в едином списке, где их можно включать/выключать, редактировать, менять их порядок отображения для любых пользователей. Это дает полный контроль над кастомизацией полей на карточке.
Механизм работает нативно: при открытии карточки система автоматически определяет, какие виртуальные поля должны быть показаны текущему пользователю, и мгновенно рендерит их, подгружая соответствующие конфигурации.
Расскажу, как механизм работает.
Создание поля
Администратор заходит в любой раздел, и в меню настройки вида выбирает пункт — «Виртуальные поля раздела».
На форме создания он указывает:
Раздел-источник (например, «Договор»);
Поле-источник из выбранного раздела (например, «Дата окончания»);
Имя для отображения (например, «Срок действия договора»).
Управление видимостью — главный инструмент кастомизации.
Здесь у нас два уровня:
Уровень доступа: Поле можно привязать к роли, группе ролей или пользователю. Например, поле «Затраты на закупку» видно только роли «Финансист».
Уровень контекста записи (фильтры): Это гибкий инструмент, базирующийся на расширенном фильтре платформы, с помощью которого можно настроить условие по любому полю Объекта. Например, нам нужно, чтобы поле «График платежей» было видно только на карточках проектов в статусе «В реализации». Тогда при создании виртуального поля мы просто задаем это условие. Условия можно комбинировать.
Цветовое окрашивание — выделяем важное.
Это очень полезный функционал, с помощью которого можно создавать цветовые подсказки или делать акцент на ключевых полях-метриках для пользователей, работающих с карточкой. Для поля можно создать набор правил раскраски.
Каждое правило включает следующие параметры :
Название: Отображаемое значение.
Условия (фильтр): [Дата окончания] < [Завтра].
Настройки цветов: Цвет текста = Белый, Цвет фона = Оранжевый.
Подсказки: «Срок истекает уже завтра!» (всплывает при наведении).
Приоритета: Если одно поле попадает под несколько правил, сработает то, у которого приоритет выше. Это позволяет выстроить логику: от частных случаев к общим.
Например, для виртуального поля Влияние в объекте Обращение настроены два правила цветового выделения:
Общее правило: Если поле содержит слово «Высокое» — установить для поля оранжевый цвет.
Частное правило: Если поле содержит слово «Высокое» и обращение от «Категории клиента» = «Партнёр» — установить для поля красный цвет.
Представим, что в службу поддержки приходят два новых обращения. Обращение №1 от обычного клиента. В поле «Влияние» менеджер вручную поставил значение «Высокое», так как проблема блокирует работу. Обращение №2 пришло от клиента, чья «Категория» в системе — «Партнёр». В поле «Влияние» также проставлено «Высокое».
В результате для Обращения №1 сработает общее правило: поле «Влияние» будет выделено оранжевым, а для Обращения №2: Сработает частное правило: поле «Влияние» будет выделено красным.
Благодаря этому поддержке удается мгновенно отделить критичные инциденты ключевых па��тнёров от остальных высокоприоритетных задач.
Границы возможного: честно об ограничениях
Решение создавалось для конкретных целей, и у него есть технические рамки:
Только карточка. Виртуальные поля не выводятся в реестр, представления детали или на мини-карточку. Они созданы именно для углубленной работы с конкретной записью и её бизнес-логикой.
Нет поиска и фильтрации. По этим полям нельзя искать или сортировать реестр, так как они не существуют на уровне SQL-запросов к БД.
Не обновляются одновременно с полем источника. Для обновления логики отображения после изменения зависимых полей нужна перезагрузка карточки.
Ограниченный набор типов. Работает с основными типами данных: текст, число, дата, ссылка, логический. Работа со справочными или ссылочными типами не предусмотрена.
Почему мы с этим смирились? Потому что это RND-решение, а не ядро платформы: мы создали инструмент в качестве дополнения к платформе и не трогали базовую логику системы.
Эти ограничения — плата за скорость, стабильность и безопасность работы (нет изменений в ядре — следовательно, нет рисков нарушить базовую стабильность и безопасность решения). Они очерчивают понятную область применения решения: расширение и дополнение базовой функциональности платформы BPMSoft, а также быстрая и безопасная кастомизация представления данных на пользовательской форме.
Сценарии из практики: как это работает в жизни
Сценарий 1: «Единый источник истины для менеджера».
Задача: В карточке «Заявка от клиента» менеджер хочет сразу видеть рейтинг клиента и общую сумму всех его оплат, не переходя в карточку Контрагента. Эта информация помогает оценить значимость клиента и принять верное решение о приоритете и подходе к работе.
Решение: Создаем два виртуальных поля: «Рейтинг клиента» (из раздела «Контрагенты») и «Сумма всех сделок» (из агрегирующего представления). Поле «Рейтинг» раскрашиваем: красный для рейтинга < 3, зеленый — для >= 4.
Сценарий 2: «Контекстные подсказки для поддержки».
Задача: Инженеру службы поддержки нужно знать, есть ли по данному клиенту неоплаченные счета, когда он обращается с проблемой. Иначе он может потратить время на клиента, оказание услуг для которого приостановлено.
Решение: В карточке «Обращение» создаем виртуальное поле «Наличие долга» (логическое, из финансовой системы). Ставим правило: если =True, то фон красный, подсказка «Клиент имеет просроченную задолженность. Оказание услуг приостановлено».
Сценарий 3: «Динамическая форма».
Задача: В случае автоматической отмены заказа, вызванной сбоем интеграции (например, с платёжной системой или складским учётом), техническая причина ошибки фиксируется только в системных логах, зачастую внутри сложных объектов данных. Чтобы упростить отслеживание и ускорить анализ подобных инцидентов, мы решили выводить эту критически важную информацию напрямую в интерфейс карточки с ошибкой — это даст техническому специалисту мгновенный доступ к необходимым данным.
Решение: Настраиваем виртуальное поле «Текст ошибки» с фильтром видимости [Статус] = "Отменен с ошибкой" и привязкой к роли «Супервайзер» и «Системному администратору». Так мы эмулируем сложное поведение формы без правки бизнес-процесса. При необходимости можем добавить текст подсказки и цветовое выделение для поля.
Заключение: Бизнес-адаптивность как сервис
Внедрение решения «Управление виртуальными полями» превратило системного администратора из «исполнителя заявок в Jira» в человека, который быстро реагирует на бизнес-потребности команды. Простые доработки, которые раньше ждали своего часа от нескольких дней до нескольких недель, теперь выполняются за 10-15 минут.
Что мы получили:
Расширение без вмешательства: Решение добавляет новый функционал для кастомизации интерфейса, работая как независимый слой поверх платформы. При этом оно никак не затрагивает и не изменяет штатные бизнес-процессы, базу данных или ядро системы — всё работает в своей «песочн��це», оставляя основную логику нетронутой.
Снижение нагрузки разработчиков: на ~30% по задачам, связанным с UI.
Удовлетворенность бизнес-пользователей: они видят реакцию на их запросы практически в реальном времени.
Это решение не панацея. Для сложной логики, интеграций или массовых операций по-прежнему нужно привлечение ресурса разработчиков. Но оно идеально закрывает повседневные нужды работы с интерфейсом карточек, делая систему ещё более живой и адаптивной.
А как вы решаете задачи быстрой кастомизации интерфейсов в ваших BPM- или ERP-системах? Есть ли встроенные low-code инструменты, или вы тоже развиваете свои RND-решения? Делитесь опытом в комментариях!
