Отдельная база данных компании в CRM: что это означает и чего не означает

Разделите уровни архитектуры

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

Рабочие данные, учётные записи, приложение и серверная инфраструктура являются разными частями. Когда поставщик говорит об отдельной базе, уточните, какой именно компонент выделен. В физической модели компаний MB CRM рабочие записи разделяются по базам PostgreSQL, но это не означает автоматически отдельный сервер, кластер или независимое приложение. Центральные учётные записи и сеансы могут оставаться общими сервисами платформы с собственной моделью управления доступом.

Уточните административные полномочия

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

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

Проверьте пользовательские операции

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

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

Обсудите резервирование и восстановление

Результат можно проверить по следующему признаку: стороны одинаково понимают, где находятся данные компании и какие общие сервисы нужны для входа и администрирования.

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

Сформулируйте ожидание понятным языком

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

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