Объединение дублей CRM: предпросмотр, выбор полей и сверка связей

Сначала подтвердите, что объединение вообще нужно

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

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

Не начинайте с большой кнопки «объединить всё». Выберите небольшую проверенную пару и перечислите объекты, которые изменятся. В Dataverse интерфейс объединения позволяет выбрать основную запись и переносимые значения; документация отдельно указывает ограничения поддерживаемых типов и полей. Microsoft Learn: Merge duplicate rows.

Подготовьте пакет до изменения

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

Для каждого объекта укажите ожидаемое действие: сохранить ссылку, переназначить владельца связи, оставить отдельно или передать на разбор. Само объединение клиента не даёт основания объединять две разные сделки, удалять документы или закрывать открытые обещания. Если два контакта связаны с одной компанией, это также не означает слияние компаний.

Опишите последствия для автоматизации. Изменение профиля может повлиять на сегмент, подготовленное сообщение или интеграцию. До операции нужно знать, какие процессы продолжатся и кто проверит результат. Не предполагайте одинаковое поведение во всех CRM: HubSpot отдельно документирует объединение свойств, активностей, связей и особенности рабочих процессов. HubSpot: Merge records.

Выбирайте значения по полям, а не карточку целиком

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

Практическая матрица может выглядеть так:

• Имя для обращения — последнее подтверждённое клиентом значение
• Телефон — действующий проверенный контакт с сохранением прежнего как исторического, если это нужно процессу
• Ответственный — сотрудник, который действительно принимает текущую работу
• Организация и роль — отдельные подтверждённые отношения, без автоматического объединения компаний
• Ограничения связи — сохраняются по каналу и цели; неизвестность не превращается в разрешение
• Свободные заметки — переносятся выборочно с источником и датой, без ненужных секретов

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

Учебный пример: две карточки, пять покупок

Условные карточки C101 и C204 подтверждены как один покупатель. Все суммы в рублях, события учебные. C101 содержит заказы O11 на 1 200, O12 на 1 800 и O13 на 900. C204 содержит O13 на 900, O14 на 1 500 и O15 на 700. У двух записей O13 совпадает проверенный идентификатор исходного заказа в той же системе-источнике.

До объединения экранные итоги равны 3 900 и 3 100. Их простое сложение даст 7 000. Но уникальных заказов пять: 3 + 3 − 1 = 5, а сумма равна 3 900 + 3 100 − 900 = 6 100. Повтор O13 должен остаться одной покупкой, сохранив обе исходные ссылки загрузки.

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

В бонусной истории C101 записаны L1: +100, L2: +50 и L3: −30 баллов. У C204 находятся L2: +50 и L4: +80. После подтверждённого устранения дубля L2 остаются четыре операции и 100 + 50 − 30 + 80 = 200 баллов. Складывать экранные остатки 120 и 130 нельзя: это дало бы 250. Реальное исправление бонусов требует проверки исходного журнала, а не ручного назначения желаемого числа.

Допустим, у каждой карточки по две открытые задачи, одна из которых — повтор T7. Тогда ожидаются три уникальные задачи. После операции сотрудник должен найти каждую и объяснить её владельца. Красивый общий баланс не компенсирует потерю незавершённого обещания.

Проверьте неизменность входных данных

Между предпросмотром и выполнением клиент может изменить контакт, а менеджер — добавить задачу. Пакет должен содержать время и версии снимка. Если затронутые записи изменились, обновите предпросмотр и повторно проверьте различия. Нельзя применять решение к более старому состоянию, не показав появившиеся данные.

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

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

Не обещайте обратимость без проверки

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

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

Чек-лист приёмки объединения

1. Оба прежних идентификатора приводят к объяснимому результату поиска.
2. У каждого конфликтующего поля есть выбранное значение и основание.
3. Пять уникальных заказов примера дают 6 100 рублей, а не 7 000.
4. Бонусные события сохраняют свои ключи; повтор L2 не увеличивает остаток.
5. Все три уникальные открытые задачи имеют владельцев и сроки.
6. Ограничения связи не исчезают после переноса профиля.
7. Внешние ссылки, документы и права доступа проверены отдельно.
8. Изменение записи после предпросмотра вызывает повторную сверку.
9. Неизвестный результат и частичный сбой не приводят к слепому повтору.
10. Исправление ошибочного объединения проверено в пределах реальных возможностей системы.

Общий перенос базы рассмотрен в руководстве по миграции клиентов. Для SABSUS уточняйте поддержку полей, связей и исправлений через CRM и доступы. Описанный пакет — требование к проверке, а не обещание встроенного merge или автоматического отката.

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

Нужно ли сохранять основную карточку с самой длинной историей?

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

Можно складывать выручку и бонусы двух профилей?

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

Что делать с парой, принадлежность которой не доказана?

Оставить раздельно, сохранить основание подозрения и назначить проверку. Ошибочная общая история опаснее временно незавершённой очистки.

Источники

• Microsoft Learn: Merge duplicate rows — основная запись, выбор значений и ограничения.
• HubSpot: Merge records — связи, свойства, автоматизация и отсутствие обратной операции unmerge.

Источники проверены 9 октября 2026 года. Карточки и расчёты вымышлены.