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