Разработка приложения Битрикс24 на заказ: от рабочей задачи до запуска

Заказное приложение Битрикс24 нужно, когда рабочий процесс не удаётся удобно собрать настройками и готовыми решениями. Стоимость зависит от сценариев сотрудников, обработки данных, интеграций и требований к запуску. До расчёта стоит определить один законченный результат первой версии, проверить доступность API и согласовать права. Затем проектируют интерфейс, реализуют рабочий сценарий, проверяют его на портале и готовят поддержку. Наличие макета или успешного API-запроса ещё не означает, что приложение готово к ежедневной работе.

Когда нужно своё приложение

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

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

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

Внутреннее приложение и продукт для Маркета тоже отличаются объёмом. Первое создаётся под согласованный процесс компании. Для тиражного продукта нужно отдельно продумать установку на разные порталы, настройки, описание и сопровождение. Это отдельное направление разработки приложений Битрикс24.

Учебный пример: выдача оборудования сотрудникам

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

Сначала ограничим первую версию. Она работает с одним видом оборудования и тремя ролями: сотрудник, выдающий специалист и руководитель. Сотрудник видит свои запросы, специалист обрабатывает выдачу и возврат, руководитель наблюдает за процессом.

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

Полезный результат первой версии формулируется так: «Сотрудник оформляет запрос, специалист выдаёт конкретный предмет, а после возврата тот снова доступен для следующего запроса». Это законченная цепочка, которую можно пройти и проверить.

Что описать до расчёта стоимости

Задание удобнее начинать с действий людей. В нашем примере нужно ответить на вопросы:

1. Кто может запросить оборудование и кому разрешено подтвердить выдачу?
2. Предмет выбирает сотрудник или выдающий специалист?
3. Когда он становится недоступен другим: при запросе, подтверждении или фактической выдаче?
4. Можно ли отменить запрос и кто закрывает ошибочную выдачу?
5. Какие сведения нужны руководителю, а какие относятся только к сотруднику?
6. Что происходит, если один и тот же предмет пытаются выдать одновременно?

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

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

Из чего складывается стоимость приложения

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

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

Интерфейс проектируют под сотрудника

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

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

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

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

Как спланировать данные и права

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

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

Права нельзя свести к одной отметке «разрешить CRM». Группа методов scope определяет доступ приложения к инструментам API, а права сотрудника влияют на доступные ему данные и действия. Справочник прав помогает проверить нужные группы методов.

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

Облако и коробка: что меняется для проекта

В облачной версии интеграции строятся через доступные возможности REST API. Коробочная версия дополнительно предоставляет Битрикс API и D7 API и позволяет адаптировать исходный код. Это различие зафиксировано в официальном сравнении версий.

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

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

Слово «локальное» в названии приложения не означает автоматически, что его сервер находится в офисе заказчика. Размещение, доступ к данным и обслуживание нужно согласовать отдельно.

Ограничения API входят в рабочий сценарий

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

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

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

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

Как принять первую версию и подготовить запуск

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

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

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

Частые вопросы

Можно ли назвать стоимость по одному описанию идеи?

Можно определить предварительный состав работ и вопросы для оценки. Для предметного расчёта нужны сценарии, данные, роли и проверка ключевых ограничений. Если неизвестно, доступно ли необходимое действие через API, это условие нужно исследовать до твёрдой оценки.

Нужно ли публиковать внутреннее приложение в Маркете?

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

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

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

Можно ли начать с одной функции и расширять приложение?

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

Что требуется от заказчика после запуска?

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

Следующий шаг

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

Официальные источники

Технические сведения проверены 20 октября 2026 года.

• Локальные приложения и их варианты.
• Доступные скоупы Битрикс24.
• Раздел «Разработчикам» и доступ к интеграциям.
• Различия облачной и коробочной версий.
• Лимиты REST API.