Коротко: что важно для бизнеса

Собственный домен делает форму или клиентский сервис узнаваемее и позволяет использовать адрес компании в рекламе и рассылках. Но брендированный URL не означает закрытый контур: текущая реализация требует открытого доступа без авторизации. Поэтому через такой интерфейс нельзя публиковать персональные данные, внутренние функции или действия, которые должны быть доступны только известному пользователю. Дополнительный операционный риск — зависимость от DNS и статуса сервера Black Hole.

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

Что именно изменилось

Приложение, форму или клиентский сервис из Вайбкода теперь можно открыть на домене компании: Битрикс24 выдаёт DNS-записи и автоматически выпускает HTTPS-сертификат.

  • К приложению на сервере Black Hole можно подключить основной домен или поддомен компании; технический адрес приложения при этом сохраняется.
  • Битрикс24 формирует TXT-запись для подтверждения владения доменом и CNAME либо A-запись для направления посетителей на приложение, а затем автоматически выпускает HTTPS-сертификат.
  • Один домен привязывается к одному приложению. При использовании Cloudflare для A или CNAME нужно отключить проксирование.
  • Сейчас собственный домен подходит только для приложений с открытым доступом: авторизация закрытого приложения на нём не работает, а страницу может посетить любой человек по ссылке.
  • Вайбкод регулярно проверяет DNS. После трёх неудачных проверок работа домена приостанавливается; привязка также приостанавливается при деактивации Битрикс24.
Настройка внешнего доступа к приложению Битрикс24 Вайбкод
Официальный интерфейс Вайбкода: сейчас собственный домен работает для приложений с открытым доступом без авторизации.
DNS-записи для собственного домена приложения Битрикс24 Вайбкод
Вайбкод формирует TXT и CNAME либо A-запись; их нужно вручную добавить у DNS-провайдера и дождаться проверки и выпуска HTTPS-сертификата.

Где обновление принесёт пользу — и где не поможет

Собственный домен делает форму или клиентский сервис узнаваемее и позволяет использовать адрес компании в рекламе и рассылках. Но брендированный URL не означает закрытый контур: текущая реализация требует открытого доступа без авторизации. Поэтому через такой интерфейс нельзя публиковать персональные данные, внутренние функции или действия, которые должны быть доступны только известному пользователю. Дополнительный операционный риск — зависимость от DNS и статуса сервера Black Hole.

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

План безопасного пилота

  1. Выбрать отдельный поддомен, который не используется сайтом, почтой, API или другим сервисом, и зафиксировать текущие DNS-записи перед изменением.
  2. Провести проверку данных и функций приложения: оставить только то, что допустимо показывать любому посетителю, и убрать секреты, внутренние идентификаторы и персональные данные.
  3. Настроить TXT и CNAME либо A-запись, отключить проксирование Cloudflare при его использовании и дождаться статуса активного HTTPS-сертификата.
  4. Проверить приложение с разных устройств и без авторизации, а также сценарии ошибочного адреса, недоступности Битрикс24 и восстановления DNS.
  5. Настроить внешний мониторинг домена и сохранить технический адрес приложения как резервный путь для диагностики.

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

Как оценить результат без самообмана

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

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

Короткие ответы

Стоит ли включать обновление сразу для всей команды?

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

Что считать успешным результатом?

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

Нужна ли отдельная настройка CRM?

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

Источник и метод. Факты сверены с материалом Битрикс24: перейти к первоисточнику ↗. Редакция CHECK CRM отделяет заявление поставщика от практической рекомендации; возможности и условия нужно повторно проверить перед запуском.