Отдельное приложение в режиме Код подойдет, если готовой CRM-формы недостаточно. Например, при регистрации сотрудников на корпоратив нужно проверять связанные даты, закрывать прием заявок по дедлайну и дать организатору отдельную страницу для работы со списком участников.

Для обычной заявки клиента отдельное приложение не нужно. CRM-форма уже умеет собирать данные, создавать элементы CRM, показывать зависимые поля, защищать форму от спама и выполнять действия после отправки.

Определить, нужна ли отдельная форма

Для простого сбора заявок отдельное приложение обычно не нужно. В Битрикс24 уже есть CRM-формы: они умеют собирать данные, создавать элементы CRM, показывать зависимые поля, защищать форму от спама и выполнять действия после отправки.

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

Например, компания хочет собрать в одном месте внутренние заявки сотрудников в административный отдел: на пропуск для гостя, ремонт, курьера или заказ техники.

Для такого приложения можно настроить собственный сценарий работы:

• показывать разные поля в зависимости от типа заявки,
• проверять введенные данные, например не разрешать выбрать прошедшую дату визита,
• дать администратору отдельную страницу со всеми заявками,
• добавить поиск и фильтры по типу, статусу или сроку,
• выгружать заявки в XLSX в нужном порядке колонок,
• разделить доступ сотрудников и администраторов,
• оформить форму и административную страницу в индивидуальном дизайне под задачи компании или фирменный стиль.

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

Подготовить требования к форме

Перед созданием формы определите, какие данные нужно собирать и что должно происходить после отправки.

Например, компания хочет собрать в одном месте внутренние заявки сотрудников в административный отдел. Сейчас сотрудники пишут в разные чаты: кто-то просит заказать пропуск для гостя, кто-то сообщает о сломанном стуле, кто-то заказывает курьера. Из-за этого заявки сложно отслеживать, а ответственным приходится вручную собирать информацию.

В режиме Код можно создать единую форму, где сотрудник сначала выбирает тип обращения, а затем заполняет только нужные поля. Например:

• для заявки на пропуск — ФИО посетителя, дату и время визита, имя принимающего сотрудника,
• для ремонта — помещение, описание проблемы и желаемый срок,
• для курьера — адрес отправления, адрес доставки и комментарий,
• для заказа техники — что нужно заказать, количество и срок.

Для каждого поля заранее определите, обязательно ли его заполнять, какие значения допустимы и какие проверки нужны. Например, дата визита не должна быть в прошлом, а количество техники — меньше одного.

Отдельно определите роли. Сотрудник заполняет форму и видит результат своей отправки, а администратор работает со списком заявок, фильтрами и выгрузкой. Если нужны уведомления, заранее решите, кто и в каких случаях должен их получать.

Также до создания формы стоит определить, кто может открыть административную страницу, можно ли исправлять и удалять заявки, сколько времени хранить ответы и в каком формате выгружать данные.

Составить запрос для создания формы

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

В запросе укажите не только, что нужно создать, но и как вы хотите работать с результатом. Например, если сначала хотите проверить приложение и внести изменения, попросите создать локальную тестовую версию и не публиковать ее сразу.

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

Соберите запрос из нескольких частей:

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

Для формы заявок это может выглядеть так: пользователь выбирает тип обращения, заполняет нужные поля, форма проверяет данные, после отправки создает заявку, а администратор видит ее в отдельном списке. Например:

Создай приложение для внутренних заявок в административный отдел.
Сотрудники должны отправлять через одну форму заявки четырех типов: пропуск для гостя, ремонт, курьер и заказ техники.

Сначала пользователь выбирает тип заявки. После этого показывай только подходящие поля.

Для пропуска запроси ФИО посетителя, дату и время визита и принимающего сотрудника. Не разрешай выбрать дату в прошлом.

Для ремонта запроси помещение, описание проблемы и желаемый срок.

Для курьера — адрес отправления, адрес доставки и комментарий.

Для заказа техники — название, количество и желаемый срок.

Сделай обязательные поля понятными, а ошибки показывай рядом с полем. После отправки покажи подтверждение и защити форму от повторного создания одной и той же заявки.

Для администраторов Битрикс24 создай отдельную страницу со списком заявок. Добавь поиск, фильтры по типу и статусу и выгрузку в XLSX.
Обычный сотрудник не должен видеть общий список заявок и выгрузку.

Оформи приложение в современном минималистичном стиле. Используй шрифт Inter, светлый фон, нейтральную цветовую палитру с одним акцентным цветом для кнопок и важных элементов. Используй аккуратные карточки, единые отступы и понятную визуальную иерархию. Не используй перегруженные декоративные элементы.

Сначала создай тестовую локальную версию приложения. Не публикуй ее, пока я не проверю работу формы, доступы, хранение данных и дизайн.

Сначала используй только тестовые данные без реальных персональных данных.

После отправки запроса агент подготовит план разработки приложения.
В правой части окна отображается список этапов: например, создание структуры приложения, разработка формы, настройка страницы администратора и проверка результата.

По плану можно отслеживать, какие задачи уже выполнены и на каком этапе находится создание приложения.

Проверить приложение перед публикацией

После создания приложения агент откроет локальную версию, где можно проверить результат до публикации.

В правой части окна отображается предпросмотр приложения. Проверьте, как работает сценарий пользователя:

• все ли нужные поля отображаются,
• корректно ли работает логика формы,
• понятны ли сообщения об ошибках,
• соответствует ли интерфейс заданному дизайну.

Для проверки используйте тестовые данные: вымышленные имена, адреса и другие значения, которые не содержат реальную информацию. Проверьте не только успешную отправку, но и ошибочные сценарии: например, заполнение без обязательного поля или ввод некорректного значения.

После отправки заявки проверьте, что данные корректно сохраняются и отображаются для администратора:

• создается ли одна запись на одну отправку,
• все ли значения передаются без изменений,
• работают ли поиск и фильтры,
• корректно ли формируется выгрузка.

Также проверьте доступы: обычный сотрудник не должен видеть список всех заявок и административные данные, а у администратора должны быть только необходимые права.

Если нашли проблему, вернитесь в тот же сеанс и опишите, что нужно изменить. Например:

В форме не показывается ошибка при заполнении обязательного поля. Добавь понятное сообщение рядом с полем.

После исправлений повторите проверку. К публикации переходите только после того, как основные сценарии работают корректно.

Опубликовать приложение

Перед публикацией приложения привяжите ключ Вайбкода к сеансу. Это можно сделать на любом этапе разработки, необязательно ждать полной готовности приложения.

Подключить ключ.

1. В личном кабинете Вайбкода перейдите в раздел API-ключи.
2. Нажмите Создать ключ.
3. Укажите понятное название ключа.
4. Нажмите Создать.
5. Скопируйте созданный ключ.
6. Вернитесь в сеанс режима Код и откройте сайдбар, если он был скрыт — нажмите на иконку в правом верхнем угле.
7. В правой панели нажмите Привязать.
8. Вставьте ключ и подтвердите привязку. После этого ключ будет подключен к сеансу.

После привязки ключа продолжайте работу над приложением в сеансе. Вы можете вносить изменения, проверять локальную версию и дорабатывать результат до тех пор, пока приложение не будет готово к публикации.

Задеплоить приложение. Когда приложение проверено и готово для пользователей, выполните деплой.

1. В правой панели нажмите Деплой.
2. Дождитесь завершения публикации.
После завершения публикации откройте приложение, проверьте основной сценарий работы и передайте ссылку пользователям.

Настроить доступ к приложению

После публикации определите, кто сможет работать с приложением. Это поможет открыть доступ нужным пользователям и скрыть приложение от тех, кому оно не предназначено.

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

1. В личном кабинете Вайбкода перейдите в раздел Приложения.
2. Выберите нужное приложение.
3. Нажмите Доступы.
4. Выберите подходящий вариант доступа. Можно выбрать:

• Только владелец — приложение доступно только автору,
• Указанные участники — доступ получают выбранные сотрудники и отделы,
• Весь портал — приложение доступно всем сотрудникам Битрикс24,
• Авторизованные — приложение доступно пользователям с учетной записью Битрикс24,
• Публичный — приложение доступно всем пользователям по ссылке.

После выбора доступ сохраняется автоматически.