CRM-платформа с low-code/no-code-настройкой: пользователь сам собирает объектную модель раздела, настраивает бизнес-процессы и маршруты согласования под свой бизнес.
TL;DR
Дизайнер раздела — сердце продукта. Это инструмент, через который клиенты адаптируют CRM под свой бизнес: выделяют нужные им сущности, проектируют объектную модель этих сущностей, «верстает» будущую страницу записи не привлекая разработку.
Собрал трёхпанельный редактор с прогрессивным раскрытием настроек, набор типов полей под разные бизнес-задачи.
На мне был весь цикл: проработка структуры инструмента, проектирование интерфейса всех типов полей и их настроек, продумывание валидации и edge-cases, защита решений перед бизнесом и командой, декомпозиция, поддержка разработки до релиза.
Ниже — общий обзор того, как устроен инструмент. После него два кейса: нумератор и деталь.
Трёхпанельный редактор
Дизайнер раздела устроен как редактор с тремя областями. Слева — общие свойства раздела. В центре — холст, на котором собирается макет страницы записи из выбранного пресета сетки. Справа — палитра типов полей и контекстная панель настроек выбранного объекта. Настройки раскрываются по мере действий пользователя.
Типы и свойства полей
Доступны: текст, число, дата, дата-время, время, чекбокс, нумератор, селект, контакт, связь, деталь. Часть типов имеет внутренние переключатели, которые меняют поведение поля. У каждого поля есть свой набор свойств.
Нумератор
Автоматическая нумерация записей с настраиваемыми масками.
Ситуация
В работе с разделами часто встречается сценарий, когда требуется автоматическая нумерация записей. Для него нужен no-code инструмент, доступный клиенту для самостоятельной настройки.
Задача
Спроектировать механизм нумерации, который работает в двух режимах: с единым счётчиком на весь раздел и с раздельными счётчиками внутри одного раздела.
Действия
Запросил примеры нумерации. Стало понятно, что внутри них скрываются два режима: в одних счётчик идёт сквозным потоком на весь раздел, в других — внутри раздела ведутся независимые счётчики по разным условиям.
Например, если Тип документа = Приказ, то номер формируется по маске «П-ДД.ММ-NNN» — например, «П-17.11-039»; если Тип документа = Входящий, то номер формируется по маске «Вх-ДД.ММ.ГГ-NNN» — например, «Вх-17.11.26-024». При этом порядковый номер может быть как один на все маски, так и в каждой свой.
Предположим, что пользователь создаёт три записи. Первые две — Приказ, третья — Входящий. Если порядковый один на все маски, т.е. нумерация сквозная, то значения будут: «П-17.11-039» → «П-17.11-040» → «Вх-17.11.26-041». Если у каждой маски свой порядковый номер, т.е. нумерация раздельная, то значения будут: «П-17.11-039» → «П-17.11-040» → «Вх-17.11.26-005».
Решил, что настройка нумерации должна быть в дизайнере раздела: отдельный тип «Нумератор». Заложил это разделение в модель нумератора — пользователь сначала выбирает тип нумерации, а дальше работает в его логике.
Маски — отдельная сущность внутри нумератора. Маску можно собрать из набора параметров: статичная строка, текущий месяц, текущий год (две или четыре цифры), текущий день, значение колонки, порядковый номер.
Внутри панели нумератора маски разнесены по двум блокам. Первый — маска по умолчанию, она может быть только одна и нужна, чтобы значение нумератора не оставалось пустым. Если пользователь подразумевает один общий формат номера — можно оставить только маску по умолчанию. Второй блок — маски по условию: их может быть несколько, и в виджете настройки такой маски добавил фильтр.
В правой панели для уже существующего нумератора добавил визуализацию ресурса — последний созданный номер, шкала заполнения, процент занятости. Это даёт представление о текущем состоянии нумератора.
Результат
В дизайнере раздела появился тип поля «Нумератор», который закрывает оба сценария нумерации в рамках одной сущности — сквозную и раздельную модели, маски по умолчанию и по условию.
Для уже работающих нумераторов в правой панели отображается состояние ресурса — текущий счётчик и шкала заполнения. Это позволяет пользователю отслеживать, насколько близок нумератор к исчерпанию, прямо из дизайнера раздела.
Деталь
Вложенная таблица на странице записи, через которую видны связанные с ней записи из другого объекта.
Ситуация
Предположим, есть два раздела: Счета и Документы. Каждый счёт связан с документом. При этом с одним и тем же документом могут быть связаны несколько счетов. Работая в разделе Документы, пользователю, чтобы проверить статус счетов или убедиться в их корректности, необходимо переходить в раздел Счета и применять фильтр по нужному документу, а затем вернуться в Документы и продолжить работу.
Деталь позволяет отображать связанные счета прямо на странице документа. Если говорить шире, то деталь позволяет отображать связанные с текущей открытой записью записи из другого объекта.
Подобные связи встречаются в любой бизнес-сущности, поэтому такие сценарии важно покрыть no-code инструментом для самостоятельной настройки пользователем.
Задача
Дать в дизайнере раздела возможность настраивать деталь — вложенную таблицу на странице записи. Чтобы пользователь мог настроить связь между объектами самостоятельно.
Действия
Заложил у детали два типа источника. Существующий — деталь смотрит в уже заведённый объект системы. Новый — деталь создаёт свой объект, который живёт только в её контексте: он не относится ни к разделам, ни к справочникам.
Настройку детали собрал внутри дизайнера раздела. Включая настройку объектной модели нового объекта: те же типы полей, тот же макет с сеткой. Получился «дизайнер внутри дизайнера».
Связь между разделом и деталью — отдельный блок настроек. По умолчанию подставляется связка по идентификатору, но пользователь может выбрать другие колонки. Добавили фильтрацию значений в селектах, чтобы связь оставалась технически возможной.
Результат
В дизайнере раздела появилась деталь, через которую на странице записи показываются связанные с ней записи из другого раздела. Один элемент закрывает оба сценария — связь с существующим объектом системы и работу с новым объектом.
Деталь собирается в дизайнере раздела, не перенаправляя пользователя в отдельный конструктор.
Итог
Дизайнер раздела — объёмный модуль. Сложнее всего было учитывать при проектировании количество взаимосвязей внутри инструмента и за его пределами.
В коммерческую эксплуатацию продукт не вышел. При проектировании опирался на прогон исходных сценариев в готовом интерфейсе: раскладывал примеры использования, которые мы получили на входе, и проверял, что каждый из них собирается. Ещё подключали ребят из смежной команды, чтобы протестировали решение. Это не подтверждает, что решение покрывает все возможные случаи у реальных клиентов, но даёт уверенность хотя бы в том, что для известных нам кейсов оно рабочее.