Bitrix24 часто становится местом, где компания видит работу с клиентом. Но это не значит, что вся реальность компании должна жить внутри CRM

Очень легко добавить в CRM ещё двадцать полей.

Но если каждое поле является копией чужого состояния, возникает новый вопрос: кто и когда гарантирует его актуальность?

Поэтому AMPE не просто «синхронизирует поля».

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

• Остаток.

• Долг.

• Статус производства.

• Плановая дата отгрузки.

• Себестоимость.

Inbound webhook позволяет внешней системе вызывать REST-методы в рамках доступных прав.

Outbound webhook позволяет Bitrix24 отправить событие на внешний handler.

Для локальных интеграций это может быть достаточно сильным и простым механизмом.

Для приложения, которое должно работать как полноценная интеграция с авторизацией и жизненным циклом доступа, применяется OAuth.

Выбор зависит не от того, что «быстрее подключить», а от того, как интеграция будет жить после запуска.

Bitrix24 сообщает: объект изменился.

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

AMPE отделяет получение события от тяжёлой обработки там, где это необходимо.

• Дальше интеграционный слой должен понять

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

Локальный webhook работает в рамках scope и прав пользователя, от имени которого он создан.

Это удобно.

И именно поэтому важно не выдавать интеграции больше, чем нужно.

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

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

«Сделка на этапе 4» — внутренний факт CRM.

«Клиент подтвердил заказ и возникло обязательство на исполнение» — уже событие для других систем.

Эти вещи нельзя считать одинаковыми автоматически.

И только такие события становятся интеграционными границами.

• AMPE определяет, какой переход действительно должен

  создать заказ; запустить согласование; проверить лимит; зарезервировать товар; создать проект; передать клиента в сервис.

У этих событий разная семантика.

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

AMPE сначала определяет, какой объект Bitrix24 должен появиться для каждого типа входящего события, какие данные обязательны и как исключаются дубли.

• Форма.

• Заказ.

• Заявка на расчёт.

• Регистрация.

• Обратный звонок.

Автоматическое объединение по одному полю иногда опаснее самого дубля.

Поэтому мы отдельно проектируем matching rules и степень уверенности, особенно если интеграция связывает CRM с юридическими или финансовыми объектами другой системы.

• Один клиент может обратиться

  с сайта; по телефону; из мессенджера; через другой email.

Изменение сделки может требовать быстрой реакции.

Большой справочник может обновляться пакетно.

Историческая аналитика — забираться отдельным потоком.

Не нужно превращать каждый атрибут в real-time событие.

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

Что будет, если 1С недоступна?

Если REST вернул ошибку?

Если пользователь удалил объект?

Если изменилась структура поля?

Если webhook пришёл повторно?

Если токен больше недействителен?

Интеграция должна иметь понятное поведение при каждом из этих классов ситуаций.

В противном случае ручная работа просто переезжает из ежедневного ввода данных в ежедневное исправление обмена.

Он работает в Bitrix24 с клиентом.

Видит подтверждённую оплату без запроса в бухгалтерию.

Не вводит повторно заказ, который уже согласован.

Не звонит на склад, чтобы выяснить фактический статус.

Не копирует номер реализации из другой программы.

А если интеграция не смогла выполнить действие, ошибка попадает не в «никуда», а в управляемый контур.