Как использовать двойные и тройные поля в Битрикс24, если нужны удобство в карточке, экспорт в Excel и работа с фильтрами без потери данных.
Двойные и тройные поля в Битрикс24 решают вполне понятную задачу: помогают компактно разместить несколько связанных значений внутри одного визуального блока. Это удобно для сотрудников, экономит место в карточке и ускоряет ввод данных. Именно в этой зоне применения инструмент показывает себя лучше всего. В одном из кейсов задача сводилась к тому, чтобы сотрудники быстро заполняли несколько связанных строк каждое утро, не создавая лишние сущности и не перегружая интерфейс.
В чем возникает проблема при экспорте двойных и тройных полей
Сложность начинается в тот момент, когда от такого поля ожидают поведения обычного CRM-поля. По своей природе двойное или тройное поле – это не отдельный тип данных вроде строки, числа или даты. Это составная конструкция, внутри которой хранятся несколько значений, разделенных служебными символами. Если внутри одного поля одновременно есть текст, числа и смешанные значения, система уже не может трактовать его как однородное поле для экспорта, фильтрации и дальнейшей аналитики.
На практике это проявляется так: в карточке и даже в списке Битрикс24 данные могут выглядеть аккуратно и понятно, а вот в Excel они либо не попадают вовсе, либо попадают в неудобном виде. Ситуация усложняется еще сильнее, если поле не просто тройное, а еще и множественное: число заполненных блоков заранее неизвестно, и тогда красивое отображение в интерфейсе превращается в труднообрабатываемую структуру при выгрузке. Именно это ограничение и нужно учитывать заранее при проектировании процесса.
Почему стандартный экспорт Битрикс24 здесь ограничен
Стандартный экспорт хорошо работает с полями, у которых есть понятный и предсказуемый тип. Например, строка экспортируется как строка, число – как число, дата – как дата. Но если в одном поле объединены несколько разных значений через внутренние разделители, экспорт уже не понимает, как корректно разложить их по колонкам.
Условно говоря, для интерфейса это один красивый блок, а для Excel – одна неструктурированная строка. Поэтому ожидать, что такое поле будет вести себя как полноценный источник для отчетов, фильтров и внешних выгрузок, не стоит. Здесь важно правильно определить назначение инструмента: он нужен прежде всего для удобства ввода и компактного отображения данных в карточке, а не как универсальная модель хранения для аналитики.
Решение №1: поле-клон для экспорта и фильтров
Самый практичный вариант для большинства процессов – оставить составное поле как интерфейсный элемент, а рядом завести отдельное поле-клон с понятным типом, чаще всего строковым. После этого бизнес-процесс или робот копирует значение из двойного или тройного поля в этот клон. Уже клон участвует в экспорте, фильтрах, отчетах и передаче данных в другие сущности. Такой подход прямо обсуждался как рабочий способ обойти ограничения выгрузки.
Да, в строковом поле могут остаться разделители между частями значения. Но это уже техническая задача, которая решается постобработкой. Например, при выгрузке можно убрать служебные разделители регулярным выражением и привести строку к удобному виду.
Пример логики:
Создается поле UF_CRM_TRIPLE_RAW_EXPORT типа строка.
Бизнес-процесс при изменении карточки берет значение составного поля и записывает его в поле-клон.
Далее при необходимости применяется очистка строки.
Пример подхода с регулярным выражением:
value = исходное значение тройного поля
value = preg_replace('/\x1F+/', ' | ', value)
result = trim(value)
В результате вместо внутренней служебной структуры получается обычная строка, которую уже можно экспортировать, искать и использовать в фильтрах.
Решение №2: пересобрать процесс через смарт-процессы
Если данных много, они повторяются, а количество блоков заранее неизвестно, лучше не пытаться упаковать все в одно поле. В таких сценариях логичнее уйти от двойных и тройных полей как модели хранения и собрать процесс через связанные смарт-процессы. Эта идея тоже возникла как альтернатива: вместо одного множественного тройного поля создаются отдельные элементы смарт-процесса, привязанные к сделке или другой сущности. У каждого такого элемента уже есть собственные поля с нормальными типами данных.
Такой подход особенно полезен, когда нужно:
Когда лучше использовать смарты вместо составных полей
Когда записей может быть 1, 5 или 10, и заранее это неизвестно
Когда данные должны участвовать в отчетах, BI-аналитике и сводных таблицах
Когда важны корректные фильтры, группировки и экспорт в Excel
Когда процесс со временем будет усложняться
Да, на старте это воспринимается как более сложная архитектура. Но зато данные становятся нормализованными, а значит – пригодными для дальнейшей автоматизации и аналитики. При необходимости значения из смарт-процессов можно автоматически собирать обратно в строковое множественное поле самой сделки для удобного отображения пользователям.
Где уместно использовать приложение, а где нужны кастомизации
Приложение Двойные и тройные поля (2 в 1, 3 в 1) в CRM и Смарт-процессах отлично подходит там, где главная цель – сделать карточку компактнее и удобнее для ежедневной работы сотрудников. Если нужно быстро ввести несколько связанных значений в одном месте и не перегружать интерфейс, это сильный сценарий применения.
Но если задача выходит за рамки интерфейса и упирается в экспорт, Excel, фильтрацию, отчеты или множественные перечисления, без дополнительной архитектуры не обойтись. В таких случаях либо добавляется поле-клон и логика обработки, либо сам процесс переносится на смарт-процессы. Именно поэтому Двойные и тройные поля (2 в 1, 3 в 1) в CRM и Смарт-процессах стоит рассматривать как удобный UI-инструмент с понятной областью применения, а не как универсальное хранилище для любой аналитической задачи.
Результат
Главный вывод из кейса простой: одна и та же бизнес-задача в Битрикс24 может решаться несколькими способами. Если нужен быстрый и компактный ввод данных – составные поля действительно удобны. Если нужен экспорт и работа с данными вне карточки – следует сразу предусмотреть поле-клон или отдельную структуру на смарт-процессах.
Вывод
При внедрении двойных и тройных полей важно не только смотреть на удобство формы, но и заранее понимать, что будет происходить с данными дальше. Если их нужно просто вводить и видеть в карточке, решение подходит отлично. Если же данные должны жить в Excel, фильтрах, BI-отчетах и интеграциях, лучше сразу проектировать дополнительный слой хранения. Тогда и интерфейс останется удобным, и дальнейшая работа с данными не превратится в компромисс.
Двойные и тройные поля в Битрикс24 решают вполне понятную задачу: помогают компактно разместить несколько связанных значений внутри одного визуального блока. Это удобно для сотрудников, экономит место в карточке и ускоряет ввод данных. Именно в этой зоне применения инструмент показывает себя лучше всего. В одном из кейсов задача сводилась к тому, чтобы сотрудники быстро заполняли несколько связанных строк каждое утро, не создавая лишние сущности и не перегружая интерфейс.
В чем возникает проблема при экспорте двойных и тройных полей
Сложность начинается в тот момент, когда от такого поля ожидают поведения обычного CRM-поля. По своей природе двойное или тройное поле – это не отдельный тип данных вроде строки, числа или даты. Это составная конструкция, внутри которой хранятся несколько значений, разделенных служебными символами. Если внутри одного поля одновременно есть текст, числа и смешанные значения, система уже не может трактовать его как однородное поле для экспорта, фильтрации и дальнейшей аналитики.
На практике это проявляется так: в карточке и даже в списке Битрикс24 данные могут выглядеть аккуратно и понятно, а вот в Excel они либо не попадают вовсе, либо попадают в неудобном виде. Ситуация усложняется еще сильнее, если поле не просто тройное, а еще и множественное: число заполненных блоков заранее неизвестно, и тогда красивое отображение в интерфейсе превращается в труднообрабатываемую структуру при выгрузке. Именно это ограничение и нужно учитывать заранее при проектировании процесса.
Почему стандартный экспорт Битрикс24 здесь ограничен
Стандартный экспорт хорошо работает с полями, у которых есть понятный и предсказуемый тип. Например, строка экспортируется как строка, число – как число, дата – как дата. Но если в одном поле объединены несколько разных значений через внутренние разделители, экспорт уже не понимает, как корректно разложить их по колонкам.
Условно говоря, для интерфейса это один красивый блок, а для Excel – одна неструктурированная строка. Поэтому ожидать, что такое поле будет вести себя как полноценный источник для отчетов, фильтров и внешних выгрузок, не стоит. Здесь важно правильно определить назначение инструмента: он нужен прежде всего для удобства ввода и компактного отображения данных в карточке, а не как универсальная модель хранения для аналитики.
Решение №1: поле-клон для экспорта и фильтров
Самый практичный вариант для большинства процессов – оставить составное поле как интерфейсный элемент, а рядом завести отдельное поле-клон с понятным типом, чаще всего строковым. После этого бизнес-процесс или робот копирует значение из двойного или тройного поля в этот клон. Уже клон участвует в экспорте, фильтрах, отчетах и передаче данных в другие сущности. Такой подход прямо обсуждался как рабочий способ обойти ограничения выгрузки.
Да, в строковом поле могут остаться разделители между частями значения. Но это уже техническая задача, которая решается постобработкой. Например, при выгрузке можно убрать служебные разделители регулярным выражением и привести строку к удобному виду.
Пример логики:
Создается поле UF_CRM_TRIPLE_RAW_EXPORT типа строка.
Бизнес-процесс при изменении карточки берет значение составного поля и записывает его в поле-клон.
Далее при необходимости применяется очистка строки.
Пример подхода с регулярным выражением:
value = исходное значение тройного поля
value = preg_replace('/\x1F+/', ' | ', value)
result = trim(value)
В результате вместо внутренней служебной структуры получается обычная строка, которую уже можно экспортировать, искать и использовать в фильтрах.
Решение №2: пересобрать процесс через смарт-процессы
Если данных много, они повторяются, а количество блоков заранее неизвестно, лучше не пытаться упаковать все в одно поле. В таких сценариях логичнее уйти от двойных и тройных полей как модели хранения и собрать процесс через связанные смарт-процессы. Эта идея тоже возникла как альтернатива: вместо одного множественного тройного поля создаются отдельные элементы смарт-процесса, привязанные к сделке или другой сущности. У каждого такого элемента уже есть собственные поля с нормальными типами данных.
Такой подход особенно полезен, когда нужно:
Когда лучше использовать смарты вместо составных полей
Когда записей может быть 1, 5 или 10, и заранее это неизвестно
Когда данные должны участвовать в отчетах, BI-аналитике и сводных таблицах
Когда важны корректные фильтры, группировки и экспорт в Excel
Когда процесс со временем будет усложняться
Да, на старте это воспринимается как более сложная архитектура. Но зато данные становятся нормализованными, а значит – пригодными для дальнейшей автоматизации и аналитики. При необходимости значения из смарт-процессов можно автоматически собирать обратно в строковое множественное поле самой сделки для удобного отображения пользователям.
Где уместно использовать приложение, а где нужны кастомизации
Приложение Двойные и тройные поля (2 в 1, 3 в 1) в CRM и Смарт-процессах отлично подходит там, где главная цель – сделать карточку компактнее и удобнее для ежедневной работы сотрудников. Если нужно быстро ввести несколько связанных значений в одном месте и не перегружать интерфейс, это сильный сценарий применения.
Но если задача выходит за рамки интерфейса и упирается в экспорт, Excel, фильтрацию, отчеты или множественные перечисления, без дополнительной архитектуры не обойтись. В таких случаях либо добавляется поле-клон и логика обработки, либо сам процесс переносится на смарт-процессы. Именно поэтому Двойные и тройные поля (2 в 1, 3 в 1) в CRM и Смарт-процессах стоит рассматривать как удобный UI-инструмент с понятной областью применения, а не как универсальное хранилище для любой аналитической задачи.
Результат
Главный вывод из кейса простой: одна и та же бизнес-задача в Битрикс24 может решаться несколькими способами. Если нужен быстрый и компактный ввод данных – составные поля действительно удобны. Если нужен экспорт и работа с данными вне карточки – следует сразу предусмотреть поле-клон или отдельную структуру на смарт-процессах.
Вывод
При внедрении двойных и тройных полей важно не только смотреть на удобство формы, но и заранее понимать, что будет происходить с данными дальше. Если их нужно просто вводить и видеть в карточке, решение подходит отлично. Если же данные должны жить в Excel, фильтрах, BI-отчетах и интеграциях, лучше сразу проектировать дополнительный слой хранения. Тогда и интерфейс останется удобным, и дальнейшая работа с данными не превратится в компромисс.
