Поля CRM Битрикс24: типы и свойства
Как отличать системные поля от пользовательских, выбирать тип значения и читать признаки обязательности и множественности перед настройкой CRM или интеграции.
Название «Срок оплаты» ещё не говорит, что перед вами: текст, дата, один срок или несколько значений. Перед настройкой обмена полезно прочитать описание поля по нескольким независимым признакам. Тогда понятная подпись не скроет несовместимый формат данных.
Системные и пользовательские: это происхождение поля
Системные поля входят в стандартную CRM: например, название, ответственный или дата создания. Их набор зависит от типа элемента. Пользовательские поля добавляют под собственные сведения, которых нет в подходящем стандартном поле.
Категория не определяет доступность записи. Например, в описании API системное title не помечено как поле только для чтения, а id помечено. Из этого не следует безусловное право изменить название любой сделки: учитываются метод, доступ сотрудника и контекст операции.
Не создавайте дубль стандартного поля только ради более удобной подписи. Сначала проверьте его назначение, тип и место хранения. Поле сделки и похожее поле контакта — разные источники, даже если их названия совпадают.
Тип поля: какие значения нужны
Начните с задачи: что сотрудник вводит, что система проверяет и что будет делать интеграция. Ниже — учебные примеры выбора, а не перечень полей конкретного портала. Названия типов интерфейса и технические обозначения API сверяйте с описанием своего поля.
| Тип | Пример задачи | Что согласовать |
|---|---|---|
| Строка | Артикул, внешний код или текстовая пометка | Для кода с ведущими нулями важнее сохранить запись, чем выполнять арифметику |
| Целое число / Число | Количество без дробей / дробная величина | Выберите допустимую точность и единицу измерения |
| Деньги | Сумма с указанием валюты | Согласуйте валюту и правила пересчёта, если данные объединяются |
| Дата / Дата и время | Календарный день / момент события | Уточните, требуется ли время и как его трактуют участники обмена |
| Да/Нет | Ответ на один однозначный вопрос | Это тип значения, а не признак «поле множественное» |
| Список | Выбор из согласованных вариантов | Разрешение выбирать несколько значений проверяют отдельно |
| Привязка | Ссылка на сотрудника или элемент CRM | Объект связи и его идентификатор нельзя заменять похожей текстовой подписью |
Не используйте строку для любой информации по умолчанию. Если значение участвует в расчётах, договоритесь о числовой модели; если это идентификатор, сначала проверьте, допустимо ли терять ведущие нули. При обмене тип и структура данных API должны совпадать с требованиями конкретного метода, а не только с тем, как значение выглядит на экране.
В справочнике типы могут отображаться как string, double, user или другое обозначение из API. Незнакомое обозначение не доказывает ошибку поля: уточните, кто его добавил и какой формат поддерживает инструмент, который будет с ним работать.
Множественность: одно значение или несколько
Тип «Список» задаёт набор вариантов, а множественность — возможность выбрать несколько из них. Например, учебное поле «Интересующие направления» может предлагать «Опт» и «Розница»: вопрос о допустимости обоих вариантов сразу решается отдельно от их названий.
В метаданных API за множественность отвечает isMultiple. На реальном экране ниже у «Наблюдателей» указано «Да». Это свойство описания поля, а не сведения о том, сколько сотрудников назначено в определённой сделке.
Для интеграции уточните, как конкретный метод передаёт несколько значений и что делает при обновлении. Не заменяйте несколько элементов строкой с запятыми без подтверждённого формата. Колонка «Множественное» сама по себе не задаёт правила добавления, замены или удаления значений.
Обязательность API и требования стадии
Справочник показывает isRequired из описания полей API. Значение «Нет» не доказывает, что менеджер сможет сохранить карточку без заполнения поля на любой стадии. Для этого проверяют отдельные настройки CRM.
В карточке нужного типа откройте настройки поля и проверьте «Обязательное» либо «Обязательное на стадии». Для элементов со стадиями посмотрите конкретную стадию и воронку. В сделках и смарт-процессах настройки обязательности проверяют по воронкам; стадийная опция доступна не на всех тарифах. Полный порядок описан в официальной инструкции.
Четыре вопроса требуют разных проверок: вернул ли API технический флаг; требует ли карточка ввод на нужной стадии; видит ли сотрудник поле; заполнено ли оно в конкретной записи. Ответ на один из них не заменяет остальные. Наш каталог описаний не проверяет стадии, настройки видимости и заполненность сделок.
Как проверить свойства в справочнике
Если справочник TrueTell уже подключён, выберите сделки, лиды, контакты или компании и найдите поле. Поиск, тип и категория работают одновременно. Для первоначальной проверки оставьте «Все поля» и «Все типы», чтобы не скрыть строку лишним ограничением.
Сравните полное имя, тип, «Обязательное» и «Множественное». Название помогает ориентироваться, но интеграция должна обращаться к правильному техническому коду. Его поиск разобран в отдельной инструкции. Для передачи нескольких описаний используйте выгрузку каталога в CSV.
Категория справочника определяется по признакам API и исходному коду. Если их недостаточно или они противоречат друг другу, она может остаться неопределённой. Такие строки ищите в «Все поля»; не считайте их автоматически системными или пользовательскими.
«Не передано API», «Не указано» и «Неверный формат» — отдельные состояния свойства. Они не равны «Нет». Обновите каталог и уточните причину, если это свойство нужно для настройки обмена. Справочник не создаёт и не изменяет поля; счета и смарт-процессы текущей версией не охвачены.
Что проверить до изменения модели данных
В штатных настройках, описанных Поддержкой24, тип и множественность пользовательского поля после создания менять нельзя. Если требуется другая модель, сначала спланируйте новое поле и перенос значений. Удаление старого поля удаляет и его данные, поэтому это не способ безопасно переключить тип.
Назначение и место хранения.
Указаны портал, сущность и смысл значения; проверено, подходит ли существующее стандартное поле.
Тип и количество значений.
Согласованы допустимые варианты, точность, единицы и необходимость нескольких значений; примеры проверены на выбранном формате.
Правила ввода и доступа.
Отдельно проверены технические свойства API, нужные стадии и воронки, видимость и права сотрудника.
Зависимости и переход.
Известны использующие поле роботы, формы, отчёты и интеграции. Порядок переноса и проверки новых значений согласован до удаления старых данных.
Если поле идёт в аналитику, отдельно проверьте тип и преобразования колонки BI: метаданные CRM не гарантируют готовность к расчёту. Подробнее — в материале о сопоставлении пользовательского поля и колонки BI.
Чтобы решить, какие поля оставить или изменить, одних технических свойств недостаточно. В разборе аудита полей CRM показано, как дополнить их назначением, историческими значениями и зависимостями.
Частые вопросы
Чем системное поле отличается от пользовательского?
Системные поля предусмотрены Битрикс24, а пользовательские добавляют для своих данных. Категория описывает происхождение поля, а тип — вид значения. Системное поле не обязательно доступно только для чтения: возможность записи проверяют отдельно.
Что означает «Множественное: Да»?
Поле допускает несколько значений. Это не означает, что в конкретной карточке уже введены два значения или что поле заполнено. Для интеграции дополнительно проверьте формат передачи нескольких значений в используемом методе.
«Обязательное: Нет» в справочнике означает, что поле можно не заполнять на любой стадии?
Нет. Справочник показывает технический isRequired из API. Настройки карточки и обязательность на стадии CRM нужно проверять отдельно для нужной сущности и воронки.
Можно ли изменить тип или множественность существующего пользовательского поля?
В штатных настройках, описанных Поддержкой24, тип и множественность после создания изменить нельзя. Если модель данных нужна другая, сначала согласуйте новое поле и перенос значений, затем проверьте связанные отчёты, роботов и интеграции.
Почему в справочнике бывает «Не передано API»?
Это означает, что соответствующего свойства нет в полученном описании. Такое состояние нельзя читать как «Нет». При null отображается «Не указано», а при неподходящем формате свойства — «Неверный формат».
Показывает ли справочник, какие поля не используются?
Нет. Он показывает описания полей, а не значения карточек, обращения роботов или зависимости интеграций. Для решения об удалении или замене нужен отдельный разбор использования.