Интеграция CRM-системы с мобильным приложением
Мобильное приложение для продаж или сервиса без CRM-интеграции — это изолированный инструмент, данные из которого менеджеры переносят вручную. Звонок клиента, задача, сделка — всё это живёт в CRM, и мобильное приложение должно получать и отдавать эти данные в реальном времени, а не батчами раз в сутки.
Выбор подхода: прямая интеграция vs middleware
Прямое подключение к CRM API из мобильного приложения — плохая практика. API-ключи хранятся в приложении (легко достать через jadx или class-dump), нет контроля бизнес-логики, нет кэша.
Правильная схема: мобильное приложение → собственный API (BFF, Backend for Frontend) → CRM. BFF выполняет аутентификацию с CRM по OAuth 2.0 или API-ключу, хранит секреты на сервере, трансформирует данные под нужды мобильного клиента.
BFF отдаёт клиенту только то, что нужно для экрана: список сделок с именем, суммой и статусом — не весь объект сделки на 40 полей. Это уменьшает трафик и время парсинга на мобильном.
Офлайн-режим и синхронизация
Торговый представитель едет к клиенту — интернет пропал в пригороде. Он делает звонок, фиксирует договорённости в приложении. Данные должны уйти в CRM, когда появится сеть.
На Android — WorkManager с NetworkType.CONNECTED. На iOS — BGProcessingTask. Локальное хранилище (Room/Core Data) буферизует изменения. При восстановлении соединения воркер читает непереданные записи и отправляет в BFF пакетами.
Конфликты: если менеджер в офисе изменил сделку через веб-интерфейс CRM, а мобильный пользователь — через приложение без сети, возникает конфликт. Простая стратегия: server wins (данные из CRM перезаписывают локальные). Сложнее: версионирование через updated_at timestamp, пользователь выбирает версию при конфликте.
Уведомления об изменениях
CRM меняет статус сделки — мобильное приложение должно узнать об этом. Варианты:
Webhook → Push: CRM отправляет webhook на BFF при событии (сделка изменена, новый лид). BFF отправляет FCM/APNs push на устройство пользователя. Низкая задержка, но требует настройки webhook'ов в CRM.
Polling: приложение каждые N минут запрашивает изменения через GET /changes?since={timestamp}. Проще реализовать, выше нагрузка на сервер. Для CRM-данных (не real-time) — приемлемо.
WebSocket: при открытом приложении — подписка на events. При закрытом — push. Лучший UX, сложнее в реализации.
Типичные сущности и маппинг
Каждая CRM имеет свои имена для стандартных объектов. При разработке слоя маппинга в BFF:
| Стандартная сущность | amoCRM | Bitrix24 | Salesforce |
|---|---|---|---|
| Сделка | Lead/Opportunity | deal | Opportunity |
| Контакт | Contact | contact | Contact |
| Компания | Company | company | Account |
| Задача | Task | task | Task |
Единая модель в мобильном приложении (Deal, Contact, Company) с адаптерами под каждую CRM в BFF — позволяет поддерживать несколько CRM или сменить CRM без переписывания клиента.
Сроки
Интеграция с одной CRM через BFF, базовые CRUD-операции, offline-буфер: 2-4 недели. Добавление push-уведомлений, разрешение конфликтов, поддержка нескольких CRM: плюс 1-2 недели. Стоимость рассчитывается индивидуально.