Настройка портала Битрикс24: что проверить перед доработками
Действующий портал Битрикс24 редко бывает пустым. В нём уже есть сотрудники, отделы, сделки, поля, роботы, приложения, вебхуки и правила доступа. Часть настроек используется каждый день, часть осталась от прежнего проекта, а назначение некоторых изменений никто уже не помнит.
Поэтому просьба «добавить ещё одну автоматизацию» может оказаться не локальной задачей. Новый робот меняет ответственного, старый бизнес-процесс возвращает прежнее значение, приложение отправляет данные во внешнюю систему, а сотрудник не видит результат из-за роли доступа.
Команда компании «Первый Приятный Интегратор» | 1PI.PRO разбирает, что проверить до доработок, чтобы не чинить портал методом случайных изменений.
Начните с проблемы, а не со списка настроек
Формулировка «портал неудобный» слишком широка. Для обследования нужен наблюдаемый симптом:
менеджер повторно вводит данные в нескольких местах;
заявки распределяются не по согласованному правилу;
руководитель не видит актуальный статус сделки;
согласование останавливается без понятного ответственного;
отчёт расходится с фактическими продажами;
бывший сотрудник остаётся владельцем элементов или интеграций;
изменение одной настройки ломает другой участок.
Для каждого симптома зафиксируйте ожидаемый результат, фактический результат, участников и момент возникновения. Это отделяет бизнес-задачу от предположения о технической причине.
Если сразу перейти к кнопкам, можно исправить внешний симптом и сохранить первопричину. Например, открыть сотруднику полный доступ вместо проверки роли — быстро, но небезопасно. В статье о правах доступа в Битрикс24 мы отдельно разбираем, почему ограничение часто выглядит как поломка.
Соберите паспорт портала
До первой доработки полезно составить короткую карту текущего состояния:
| Слой | Что зафиксировать | Зачем | |---|---|---| | Организация | отделы, руководители, подчинённость | понять, кто участвует в процессах и правах | | Пользователи | активные, уволенные, администраторы, внешние специалисты | убрать зависимость от случайных учётных записей | | CRM | режим, воронки, стадии, поля, обязательность | увидеть реальную логику продаж и данных | | Автоматизация | роботы, триггеры, бизнес-процессы, расписания | найти действия, которые меняют элементы | | Интеграции | приложения, вебхуки, телефония, почта, сайт, 1С | определить внешние зависимости | | Доступы | роли CRM и отдельных инструментов | проверить видимость, изменение, экспорт и удаление | | Данные | дубли, пустые обязательные поля, старые справочники | оценить качество основы для автоматизации |
Карта не должна превращаться в многомесячное описание каждой галочки. Её задача — показать критичные связи и владельцев: кто понимает настройку, кто может её изменить и какой процесс зависит от результата.
Проверьте структуру компании и пользователей
В Битрикс24 структура компании — не декоративное дерево. Отделы, руководители и подчинённость участвуют в распределении доступа и работе инструментов. Если реальная организация изменилась, а структура портала осталась прежней, новые настройки будут опираться на неверную модель.
Проверьте:
Все ли действующие сотрудники находятся в правильных отделах.
Совпадают ли руководители с фактической ответственностью.
Нет ли активных учётных записей уволенных сотрудников и прежних подрядчиков.
Кто является администратором портала и зачем ему нужны эти права.
На чьих учётных записях созданы интеграции и критичные настройки.
Кому будут переданы элементы, задачи и процессы при увольнении сотрудника.
Не удаляйте пользователя только потому, что его имя кажется незнакомым. Сначала проверьте связанные элементы, роботов, вебхуки и ответственность. Неверный порядок может оставить сделки и автоматизации без владельца.
Отделите настройку CRM от всего портала
CRM — важный, но не единственный слой Битрикс24. Перед доработками нужно понять выбранный режим работы с лидами и сделками, назначение воронок, смысл стадий и правила заполнения полей.
Спросите по каждой воронке:
какой процесс она отражает;
что означает переход между стадиями;
кто отвечает за сделку на каждом этапе;
какие поля обязательны и в какой момент;
какие отчёты используют эти данные;
что запускается при смене стадии;
куда передаётся результат после продажи.
Если смысл поля или стадии никто не может объяснить, это сигнал к проверке, а не разрешение на удаление. Поле может использоваться в отчёте, фильтре, роботе, шаблоне документа или внешней интеграции.
Список автоматизаций нужно читать как последовательность действий, а не как набор независимых блоков. Один робот меняет стадию, второй назначает ответственного, третий запускает бизнес-процесс, а приложение реагирует на уже изменённый элемент.
Для каждой критичной автоматизации зафиксируйте:
точку запуска;
условия выполнения;
изменяемые поля;
создаваемые задачи и элементы;
уведомления;
внешние вызовы;
владельца и дату последнего изменения;
контрольный сценарий.
Особое внимание уделите одинаковым действиям в нескольких местах. Если ответственный назначается CRM-формой, роботом и бизнес-процессом, результат зависит от порядка исполнения. Добавлять четвёртое правило опасно, пока не определён единственный владелец логики.
Если действующий портал уже содержит десятки роботов, полезно сначала построить маршрут одного элемента от создания до завершения. Это даст больше информации, чем простое перечисление всех настроек.
Проверьте приложения, вебхуки и внешние сервисы
Интеграция может продолжать работать годами и при этом не иметь понятного владельца. Перед доработками составьте реестр:
название приложения или интеграции;
какую бизнес-задачу она решает;
какие данные читает и изменяет;
под чьей учётной записью работает;
где хранятся ключи и кто имеет к ним доступ;
какой сервис находится на другой стороне;
что произойдёт при отключении;
где смотреть ошибки и журнал обмена.
В разделе разработчика Битрикс24 можно инвентаризировать установленные приложения и вебхуки. Но сам список не объясняет назначение каждой связи. Его нужно сопоставить с документацией приложения, договором и владельцем процесса.
Не отключайте неизвестный вебхук «для проверки» в рабочее время. Сначала определите, какие события и системы от него зависят, подготовьте резерв и тестовый сценарий.
Пересмотрите права как модель ответственности
Права доступа проверяют после структуры и процессов, но до запуска новых функций. Роль должна отвечать на четыре вопроса: что сотрудник видит, что может создавать, что может изменять и что может удалить или выгрузить.
Проверяйте не только общие права CRM. Отдельные настройки могут действовать для телефонии, задач, диска, смарт-процессов, структуры компании и других инструментов.
Безопасный принцип — не «всем всё закрыть» и не «всем всё открыть», а дать достаточно для выполнения роли. Перед изменением роли проведите тест под учётной записью представителя каждой группы.
Если для обследования приглашается подрядчик, используйте отдельную учётную запись и согласованный объём работ. Не передавайте ему логин сотрудника. Порядок безопасного подключения описан в статье «Как пригласить интегратора в Битрикс24 и не отдать лишний доступ».
Оцените качество данных
Автоматизация не исправляет автоматически дубли, пустые поля и разные правила ввода. Она может быстрее распространить ошибку по отчётам и связанным системам.
До доработок возьмите выборку реальных элементов и проверьте:
заполнены ли ключевые поля;
одинаково ли сотрудники используют справочники;
есть ли дубли компаний и контактов;
совпадают ли ответственные с фактической работой;
остаются ли элементы на промежуточных стадиях без причины;
можно ли восстановить источник обращения;
достаточно ли данных для отчёта или следующего шага процесса.
Важно проверять не только идеальную демонстрационную сделку. Возьмите успешный, проблемный, повторный и отменённый сценарии. Так становятся видны исключения, которые новая автоматизация должна учитывать или осознанно оставлять человеку.
Что можно проверить самостоятельно
Безопасная самостоятельная подготовка включает:
Список бизнес-проблем с примерами элементов и временем события.
Перечень отделов, пользователей, администраторов и внешних специалистов.
Список воронок и их владельцев.
Реестр приложений, вебхуков и внешних сервисов.
Скриншоты критичных настроек без персональных данных и секретов.
Пять контрольных сценариев, которые должны работать после доработки.
Копию действующих регламентов и инструкций.
Не выгружайте секреты и токены в общий документ. Достаточно записать владельца доступа и безопасный способ передачи на этапе работ.
Специалист нужен до изменения рабочего портала, если:
нет владельца существующих настроек;
портал создавался несколькими подрядчиками;
роботы, бизнес-процессы и приложения меняют одни поля;
используются 1С, телефония, сайт, почта или другие внешние системы;
меняется режим CRM или структура воронок;
нужно перераспределять права и ответственность;
есть риск остановить продажи или обслуживание;
необходимо сохранить историю и действующие данные.
Результатом обследования должны стать карта текущего состояния, список проблем и зависимостей, приоритеты, границы первой версии, план тестирования и перечень настроек, которые нельзя менять без дополнительной проверки.
Чего не стоит делать
Не рекомендуем:
устанавливать новые приложения «на пробу» в рабочем портале без проверки доступа к данным;
удалять неизвестные поля, роботов и вебхуки;
одновременно менять структуру, права, воронки и автоматизации;
открывать полный доступ, чтобы временно убрать ошибку;
проверять результат только под учётной записью администратора;
переносить идеальную схему процесса без проверки реальной работы сотрудников;
считать количество настроек показателем качества портала;
начинать крупную доработку без контрольных сценариев и владельца приёмки.
Частые вопросы
Что проверить в портале Битрикс24 в первую очередь?
Начните со структуры компании, активных пользователей и администраторов, режима CRM, воронок, критичных автоматизаций и внешних интеграций. Затем сопоставьте их с конкретной бизнес-проблемой.
Можно ли удалить старые поля и роботов?
Только после проверки зависимостей. Поле или робот может использоваться в отчёте, шаблоне, бизнес-процессе, фильтре или внешней интеграции.
Зачем проверять структуру компании?
Отделы, руководители и подчинённость влияют на доступ и работу инструментов. Устаревшая структура заставляет новые настройки опираться на неверные роли.
Как понять, кто изменяет данные в сделке?
Сопоставьте историю элемента с роботами, бизнес-процессами, приложениями и вебхуками. Проверяйте весь маршрут после создания, а не только последнюю настройку.
Нужно ли сначала навести порядок во всех данных?
Нет. Определите данные, необходимые для приоритетного процесса и контрольных сценариев. Остальную очистку можно планировать поэтапно.
Что должно остаться после обследования портала?
Карта структуры и интеграций, перечень проблем, владельцы настроек, приоритеты, границы изменений, сценарии тестирования и план отката или исправления.
Можно ли дорабатывать рабочий портал без остановки?
Часто да, если изменения разделены на этапы, есть тестовые сценарии и понятны зависимости. Риск и порядок определяются после обследования конкретной конфигурации.
Результат для бизнеса
Хорошая доработка начинается не с новой функции, а с понимания действующей системы. Собственник должен видеть, какой процесс меняется, какие данные и интеграции затронуты, кто принимает результат и как проверить, что старые рабочие сценарии не сломались.