Конфликты синхронизации записи и CRM: как не потерять изменения

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

Особенно опасна передача полного снимка карточки при изменении одного значения. Вместе с актуальным телефоном в получатель попадают устаревшие дата, услуга и статус. HTTP-ответ об успехе показывает лишь принятие запроса, а не сохранение всех более свежих решений.

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

Начните проектирование с карты полей и действий. Для каждого значения запишите источник, допустимые направления, поведение при пустом поле и условия изменения. Это проще проверить, чем общее обещание «полная синхронизация в реальном времени».

Версия показывает, на каком состоянии основывалось изменение. Например, менеджер открыл карточку версии 12, но до сохранения клиент перенёс визит и появилась версия 13. Система должна заметить, что попытка обновления основана на старом состоянии, и не применять её как безусловно новую.

Один из стандартных механизмов HTTP для этой задачи описан в RFC 9110: условный запрос If-Match позволяет серверу проверить валидатор представления перед изменением и помогает предотвращать потерянные обновления. При невыполненном условии изменение не применяется; конкретное поведение определяется протоколом. Поддержку такого механизма нужно проверять в API поставщика.

Если API не предоставляет условного обновления, интегратор должен описать другую стратегию: ограничение направлений изменения, последовательную обработку на своей стороне, журнал ожидаемых состояний или ручное разрешение спорных случаев. Обычная последовательность «прочитать, затем записать» оставляет промежуток для чужой правки и не даёт той же гарантии.

Версии двух разных систем не сравниваются как общий счётчик. Номер 20 в CRM не обязательно новее номера 15 в календаре. Храните происхождение изменения и соответствие локальных версий, а глобальные выводы делайте только при наличии согласованного механизма.

Изменение даты в CRM следует трактовать как намерение перенести визит, если именно календарь владеет доступностью. Сначала проверяются ресурс, длительность и новый интервал. При отказе в CRM должен появиться понятный результат; показывать несогласованную дату как окончательную опасно.

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

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

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

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

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

На демонстрации интеграции MySlot с Bitrix24 или amoCRM попросите показать именно конфликт правок. Наличие интеграционной страницы не доказывает поддержку условных запросов, конкретного журнала версий или любого направления обмена. Зафиксируйте реальное поведение выбранного подключения в требованиях и тестах.