Цифровые рабочие места

Какие требования предъявляются к цифровым рабочим местам, как происходит публикация и на что стоит обратить внимание при разработке.

Гайд дополняет общие документы Битрикс24 Маркетплейса — Общие требования к решениям и Порядок публикации решений в Маркетплейсе — и не заменяет их: цифровое рабочее место проходит модерацию и по общему регламенту тоже. Здесь собраны только требования, специфичные для цифровых рабочих мест. По этому же документу мы также проверяем уже опубликованные решения — так что он пригодится и после публикации.

Что считается цифровым рабочим местом

Цифровое рабочее место — специальный тип решений в каталоге Битрикс24 Маркетплейс: преднастроенный комплекс смарт-процессов для автоматизации бизнес-сценариев вне CRM. Может включать один или несколько смарт-процессов, каждый со своей структурой — карточками, воронками, стадиями, роботами, правами доступа.

Формат поставки — архив, полученный встроенным инструментом экспорта цифрового рабочего места. Мы принимаем к публикации только такой архив.

Чем это отличается от Отраслевой CRM. Отраслевая CRM настраивает лиды, сделки и их стадии; цифровое рабочее место — нет, оно автоматизирует сценарии на смарт-процессах вне CRM. Если ваш архив меняет лиды, сделки, их стадии или связанные справочники CRM, решение будет отнесено к отраслевым CRM и проверено по требованиям к Отраслевым CRM — у этих двух типов решений разные регламенты, и смешивать их не стоит.

Как создать и опубликовать цифровое рабочее место

  1. Настройте рабочее место на своем портале обычными пользовательскими средствами — смарт-процессы, воронки и стадии, поля и справочники, карточки, роботов и триггеров, бизнес-процессы, роли и права.
  2. Приведите решение в порядок: уберите тестовые типы, проверьте названия и коды, заполните справочники, проверьте настройки роботов (подробнее — в разделах ниже).
  3. Выгрузите архив встроенным инструментом экспорта.
  4. Установите архив на чистый портал (не на портал разработки) и пройдите весь сценарий целиком — это лучший способ увидеть решение глазами клиента.
  5. Добавьте решение в кабинете разработчика с типом приложения «Настраивать CRM» и запросите скоуп CRM.
  6. Прикрепите архив в карточку версии, заполните карточку решения и отправьте на модерацию.

Если вместо архива цифрового рабочего места прикрепить архив экспорта CRM-настроек, решение попадет не в тот регламент проверки, и мы вернем его на доработку. Категорию каталога и теги подборок при необходимости можно согласовать с модерацией отдельно.

Как мыслить продуктово

Цифровые рабочие места ориентированы прежде всего на энтерпрайз-сегмент — компании со сложными процессами и потребностью в глубокой автоматизации отдельных направлений. Готовое рабочее место позволяет им быстро развернуть отлаженные смарт-процессы для конкретного отдела (HR, бухгалтерии, юридической службы) без настройки с нуля. Поэтому больше всего ценятся продуманная бизнес-логика, гибкость, масштабируемость и понятная документация о том, как адаптировать решение под внутренние регламенты клиента.

Что переносится архивом

Справочники CRM; воронки смарт-процессов и стадии; пользовательские поля любых типов, кроме «привязки к инфоблоку»; карточки и представления; настройки роботов и триггеров; бизнес-процессы смарт-процесса; роли и права доступа.

Есть несколько моментов, о которых стоит знать заранее:

  • Связи между смарт-процессами архивом не переносятся. Раздел «Связи» в архив не попадает, и после установки у клиента ни одна связь не настроена автоматически — это особенность платформы, а не ошибка. Если решение спроектировано на связях, приложите к нему инструкцию по восстановлению: таблицу «родительский смарт-процесс → дочерний», признак вкладки дочерних элементов и путь к настройке, а смарт-процессы называйте по имени, а не числовым id (id на портале клиента будет другим). Восстановление связей стоит сделать первым шагом инструкции по установке — тогда клиенту не придется гадать, почему часть интерфейса выглядит пустой.
  • Вся автоматизация должна поставляться внутри архива. Программно, через REST, добавить робота на стадию после установки нельзя — такого метода в API нет, поэтому сценарий «наше приложение само донастроит роботов после импорта» не сработает. Все, что должно настроиться автоматически, лучше сразу включить в архив. Вручную через интерфейс администратор портала, конечно, может добавить робота в любой момент — это обычная настройка Битрикс24, речь не про нее.
  • Элементы смарт-процессов (сами данные) архивом не переносятся — но реальные данные все равно могут попасть в архив через справочники, названия полей и тексты роботов (это переносится). Перед подготовкой скриншотов стоит убрать тестовые и демонстрационные элементы с портала, а в справочники, тексты роботов и скриншоты не включать настоящие ФИО, телефоны, e-mail и ссылки на соцсети.

Стандарт разработки

Именование и коды

  • Переменные, константы и параметры бизнес-процессов лучше называть на английском, в snake_case и по смыслу (user_file, а не fail_polzovatelya или var1) — эти коды видит партнер, который будет дорабатывать решение у клиента, и ему проще в них ориентироваться.
  • Коды пользовательских полей — в платформенном формате UF_CRM_<typeId>_<КОД> (typeId — малый идентификатор типа смарт-процесса), с осмысленной английской частью; платформа не примет код в другом формате.
  • У каждого поля стоит дать человекочитаемую подпись на языке бизнеса, а не оставлять код или заглушку вида «Поле 1» — при создании полей через REST подпись по умолчанию совпадает с кодом, и это часто упускают.
  • Названия стадий лучше формулировать по состоянию элемента на языке бизнеса («Согласование юристом», «Полис выпущен»), а не «Стадия 1» или «В работе 2» — так клиенту сразу понятно, что происходит.
  • Названия смарт-процессов и воронок стоит давать по бизнес-сущности («Договор-полис»), а не абстрактно («Процесс 1»); тестовые и черновые типы перед публикацией лучше убрать.
  • Названия смарт-процессов должны быть уникальны внутри решения и включать отличительный элемент (название рабочего места или отрасли) — иначе платформа не сможет однозначно определить нужный процесс по имени.

Поля, справочники и карточки

  • Поля, которые пользователь заполняет при создании элемента (особенно обязательные), стоит пометить «Редактировать в списке» — иначе в форме быстрого создания вместо поля ввода останется только подпись, и заполнить их сразу не получится.
  • Поля, без которых элемент не имеет смысла (предмет, контрагент, сумма, срок, ответственный), лучше сделать обязательными — это единственный способ не дать маршруту запуститься на пустых данных.
  • Справочники (поля-списки) стоит поставлять уже заполненными значениями, а не заглушкой — так клиенту не придется наполнять их с нуля.
  • Тип поля лучше подбирать по смыслу данных: суммы — «деньги», сроки — «дата» или «дата-время», выбор из набора — «список», признак — «да/нет», количество — «число».
  • Хорошо, если карточка смарт-процесса отличается от стандартной: поля распределены хотя бы по одному пользовательскому разделу, а служебные поля убраны.
  • Рекомендуем включить флаг «показывать в списке» у полей, по которым пользователь ориентируется в перечне (номер, контрагент, сумма, срок).

Роли, ответственные и права

  • Ответственного за задание или задачу лучше определять через поле карточки или роль («Юрист», «Руководитель направления»), а не через конкретного пользователя или отдел портала-разработчика — на портале клиента таких пользователей либо нет, либо это будут совсем другие люди.
  • Права доступа к смарт-процессам стоит настраивать на роли по должностям, а не персонально: сами роли архив переносит, а персональные привязки — нет, так что после установки они все равно слетят. Состав ролей и то, что каждая роль видит и может менять, хорошо бы описать в документации. Рядовым участникам процесса права администратора обычно не нужны.
  • В шаблонах бизнес-процессов и роботах не должно остаться ссылок на вашу инфраструктуру — вебхуков, внешних URL, токенов: если такой вебхук попадет в архив, это будет означать доступ к вашему порталу для всех, кто установит решение.

Роботы и триггеры

  • Робота, который меняет стадию, лучше ставить последним в списке роботов стадии — при смене стадии платформа прекращает обработку остальных роботов текущей стадии, и то, что стоит ниже (уведомления, задачи), просто не успеет сработать.
  • Для перехода между воронками одного смарт-процесса стоит использовать робота смены воронки с явно указанными целевой воронкой и стадией. Робот «Сменить стадию» со стадией из другой воронки не сработает и не покажет ошибку — элемент останется на прежней стадии.
  • У робота «Создать элемент CRM» стоит заполнить список полей — как минимум название, ответственного и привязку к родителю, — иначе на портале клиента будут появляться элементы без имени, ответственного и связи с источником.
  • Пауза робота — от 10 минут до 366 дней; для более быстрой реакции лучше использовать триггеры и события, а не паузу.
  • Там, где порядок роботов на стадии важен, стоит явно задать условие «после предыдущего» — по умолчанию роботы стадии выполняются параллельно, и уведомление может уйти раньше, чем заполнено нужное поле.
  • Роботов без действия или с незаполненными параметрами лучше в решении не оставлять.

Задания, задачи и уведомления

  • Принятие решений и заполнение полей удобнее вести через задания бизнес-процессов; там, где задание не подходит, — через задачу с привязкой к элементу (без привязки ее не будет видно в карточке и таймлайне).
  • В уведомлении о новом задании хорошо бы дать прямую ссылку на него — так исполнителю не придется искать задание по списку.
  • Стадию согласования или проверки стоит удерживать до закрытия соответствующей задачи или задания (режим «ждать завершения задачи») — иначе элемент может уйти дальше по маршруту раньше, чем согласующий успеет отреагировать.
  • В действиях «Поставить задачу» и «Запланировать дело» стоит заполнить описание: что сделать, по какому элементу, что считается завершением.
  • Название задачи с чек-листом лучше формулировать по сути работы, а не общей фразой («Задача», «Проверка») — имя самого чек-листа в мобильном приложении не задать, и без содержательного названия задачи смысл теряется.
  • Тексты уведомлений, задач и записей в таймлайне стоит проверить на нераскрытые выражения вроде {=Document:UF_CRM_...} — если в выражении опечатка, оно уходит клиенту как есть, без ошибки.
  • Хорошо, если в таймлайне элемента остается лог ключевых событий процесса — это единственный способ для клиента увидеть историю решения внутри карточки.

На что обратить внимание при переносе

  • Проверяйте решение на чистом портале. Многие тонкости переноса — пропавшие связи, недоступные для заполнения поля, потерянные стадии и роботы — видны только после установки архива на чистый портал; на портале разработки все, как правило, выглядит исправным. После установки стоит отдельно открыть раскладку карточки каждого смарт-процесса и убедиться, что все размещенные в ней поля действительно существуют и доступны для заполнения — раскладка может ссылаться на поля, которых после установки нет или которые недоступны для ввода, и это видно только на установленной копии. Скриншоты и описание лучше готовить именно по результатам такого прогона.
  • Поле «Привязка к элементам CRM» — это не связь: оно не создает ни вкладку дочерних элементов, ни поле «родительский элемент». В описании его лучше не называть связью, чтобы не создавать у клиента ложных ожиданий.
  • Поле «родительский элемент» (PARENT_ID_<entityTypeId>) — виртуальное, платформа создает его сама при настройке связи. Дублировать его своим полем не стоит — это может сломать штатную навигацию.
  • У платформы есть ограничения на связи: Контакт и Компания не могут быть родителем, Заказ — ребенком, тип нельзя связать сам с собой, системные связи менять нельзя. Если попытаться настроить такую связь, платформа не покажет ошибку, но и связь не создаст — стоит иметь это в виду при проектировании.
  • Порядок стадий лучше проверить перед экспортом: если финальные стадии стоят выше по сортировке, добавить еще одну семантическую стадию (успех или провал) не получится, а роботы, которые должны были встать на эту стадию, потеряются.
  • Повторный импорт архива не обновляет решение у клиента, а создает полную копию рядом. Стоит заранее предупредить об этом в инструкции по установке и описать, как убрать лишнюю установку; обещание «обновится автоматически при переустановке» лучше не давать. Вместо этого стоит описать реальный сценарий перехода на новую версию — установку новой версии рядом с переносом данных либо чистую установку на новом портале или в новом разделе.
  • Требования и тариф отраслевой CRM (режим работы с лидами, скриншоты стадий лидов и сделок, тариф от Базового) к цифровому рабочему месту не относятся — минимальный тариф здесь Enterprise, и путаница в описании обычно означает доработку.

Тарифы, права и внешние сервисы

Смарт-процессы технически доступны с тарифа Профессиональный, но у категории «цифровые рабочие места» есть отдельное платформенное ограничение: устанавливать такие решения можно только на тарифе Enterprise. В описании и на лендинге лучше использовать прямую формулировку «работает на тарифе Enterprise»; формулировки вроде «на платных или старших тарифах», «от Профессионального» и упоминание бесплатного тарифа мы не принимаем.

Настройка и установка требуют прав администратора CRM — уровень прав для установки и для настройки связей стоит указать в карточке. Права внутри решения лучше настроить по ролям, чтобы рядовым участникам процесса не требовались права администратора.

Все сопутствующие приложения Маркетплейса стоит перечислить в описании с назначением и условиями оплаты — мы сверяем список на тестовом портале. Если среди них есть решения из подписки «Битрикс24 Маркетплейс», само решение публикуется на условиях подписки. Платные внешние сервисы и дополнительный платный функционал лучше указать с вариантами стоимости.

Требования к публикации

Чтобы решение прошло модерацию, у цифрового рабочего места — помимо стандартных требований к решениям Маркетплейса — должно быть:

  • Название, которое отражает автоматизируемый процесс или подразделение, без обещаний настройки лидов, сделок и воронки продаж («Рабочее место отдела кадров», а не «Готовая CRM для...»).
  • Краткое описание в одно-два предложения, не дублирующее название: для кого решение и какие один-два ключевых сценария оно закрывает.
  • Полное описание, подробно перечисляющее все, что установится: смарт-процессы и их назначение, воронки и стадии по порядку, ключевые поля, переменные, константы, справочники, автоматизации — мы сверяем этот перечень построчно с фактически установившимся решением. Любая настройка, которая попала в архив, должна быть подтверждена скриншотом или названа текстом.
  • Указание тарифа и прав по разделу выше.
  • Инструкция по восстановлению связей между смарт-процессами (если решение на связях) — первым шагом инструкции по установке.
  • Предупреждение о повторном импорте и порядок удаления лишней установки.
  • Заполненное поле «Описание процесса установки»: что делать после импорта, что донастроить (ответственных, права, связи, константы), какие права нужны устанавливающему.
  • Скриншоты: всех стадий всех воронок; настроенных роботов и бизнес-процессов; карточек смарт-процессов (по одному на тип); связей и туннелей — в состоянии после восстановления связей; примеров работы автоматизации в таймлайне. Скриншоты именно смарт-процессов — стадии лидов, воронки сделок, слайдер воронки продаж или карточка сделки и лида сюда не подойдут, это скриншоты для отраслевой CRM. Формат JPEG или PNG, не более 1280×720, с реалистичными демо-данными без реальных контактов и имен, соответствующими текущей версии архива.
  • Иконка — квадратная, JPEG или PNG без прозрачного фона, 250–650 пикселей (расхождение сторон не больше 10), без анимации, GIF и чужих товарных знаков.
  • Заполненная поддержка (каналы связи и регламент) и рабочие ссылки на лицензионное соглашение и политику конфиденциальности — открываются на просмотр, а не на скачивание; в лицензионном соглашении верно названы лицензиар и приложение. Вместо лицензионного соглашения нельзя приложить оферту на использование сервиса или договор оказания услуг — это самая частая причина возврата по документам.
  • Условия распространения решения заполнены и не противоречат описанию.
  • Описание не обещает того, чего архив не переносит или платформа не поддерживает: автоматических связей, автообновления при переустановке, программной донастройки роботов приложением после установки.
  • Грамотная и полностью заполненная карточка, без битых изображений.

Также рекомендуем: приложить схему процесса с точками принятия решений, ролями и автоматизацией; сделать обучающее видео со ссылкой в описании; подготовить текстовую инструкцию и FAQ со ссылками в «Полном описании» и в поддержке; собрать подборку приложений Маркетплейса, которые расширяют функционал решения; согласовать с модерацией категорию и теги подборок — действующий набор («Готовые решения — Готовые CRM», теги «crm + отрасль») сделан под отраслевые CRM, и если подходящего тега нет, лучше спросить в чате модераторов, чем брать близкий по смыслу.

На что будет обращать внимание модератор

Модератор устанавливает решение на тестовый портал и смотрит на то, что реально установилось, — не на описание. Обычно сверяются: состав, названия и порядок стадий внутри каждой воронки — с полным описанием и скриншотами (а вот порядок самих воронок друг относительно друга не принципиален, это не нарушение); справочники и поля-списки — на отсутствие тестовых и посторонних значений; тексты роботов, заданий и уведомлений — язык публикации, отсутствие заглушек, транслита и нераскрытых выражений вроде {=Document:UF_CRM_...}; карточки — по скриншотам для каждого типа; список установленных на тестовом портале приложений — все, что не заявлено в описании, мы просим добавить; тарифное указание — прямая формулировка, без упоминания бесплатного тарифа; лендинг, если есть, — совпадает с карточкой; документы — лицензионное соглашение и политика открываются на просмотр, лицензиар и название верны; общая грамотность и заполненность карточки.

Если находится расхождение, мы возвращаем решение целиком на доработку, а повторную проверку проводим заново — по карточке и свежей установке архива на тестовый портал.

Инструмент «Генератор ЦРМ»

«Генератор ЦРМ» — чат-бот в Мессенджере Битрикс24, опубликованный в Маркетплейсе (сам он не появляется в списке чатов — его можно найти поиском). С его помощью можно собрать на портале черновик цифрового рабочего места: смарт-процессы с воронками и стадиями, поля карточек, роботов на стадиях и шаблоны бизнес-процессов. Подробности — в карточке приложения.

Пользоваться генератором не обязательно, и он не заменяет ни один пункт этого гайда: решения, собранные вручную и с его помощью, проходят одну и ту же модерацию. Результат работы генератора стоит воспринимать как черновик — перед экспортом его хорошо бы проверить и доработать вручную: названия и коды, типы полей и наполнение справочников, состав и порядок роботов, ответственных и права, тексты уведомлений и заданий. За содержимое опубликованного архива отвечает разработчик решения.

Продолжите изучение

Предыдущая
Требования к отраслевым CRM
Следующая
Чеклист перед модерацией