Перенос дел типа “Письмо” с вложениями из сделок и контактов Битрикс24 в компании Битрикс24 с удалением дубликатов

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

Почему стандартный функционал привязки дел не всегда устраивает заказчика? Рассмотрим на примере конкретного запроса.

Наш клиент работает с коробочной версией Битрикс24. Стандартный алгоритм привязки звонков и писем работает следующим образом:

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

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

1.3. Если у вас несколько активных сделок по клиенту и клиент не отвечает вам на письмо (т.е. нет связи между письмами), а просто отправляет новое письмо, то оно привяжется в последнюю созданную активную сделку.

1.4. Входящий звонок также сохраняется только в самой последней сделке/лиде.

1.5. Исходящий звонок сохраняется в конкретной сделке/лиде, только если совершен через карточку этой сделки/лида.

1.6. Если есть контакт/компания с таким номером телефона, то исходящий звонок прикрепится обязательно к контакту/компании.

1.7. Если есть и контакт, и компания с таким номером, звонок прикрепится и туда, и туда.

Нашему клиенту такой функционал не подходит по ряду причин.

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

Заказчику важно вести всю цепочку коммуникации с клиентом в сущности Компания, так как именно компания является по логике родительской сущностью и для контактов, и для сделок, и все дела по каждой компании не должны быть разбросаны по отдельным сделкам (в чем может вообще отсутствовать логика) и по контактам (которые могут быть уже не актуальны).

Резюмируем задачу заказчика:

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

Перенос дел типа “Письмо” из карточки контакта в карточку компании

Перенос дел типа “Письмо” из сделки в контакт/компанию

Далее рассмотрим, как настроить такую автоматизацию с помощью интеграций в Пинкит.

2.1. Шаг 1 - Откуда

Получаем данные из Битрикс24 в момент создания дела. Можем отфильтровать дела по ответственному с помощью дополнительных запросов, если это необходимо. Укажем тип дела "Письмо".

2.2. Шаг 2: Инструменты

Используем API-запрос методом GET с урлом /crm.contact.company.items.get?id={{source.OWNER_ID}}.

Используем инструмент проверки по полю step1.result. Если значение будет пустым, интеграция прервется.

Используем перебор по полю step1.result.

2.3. Шаг 3 - Куда

Добавляем привязку дела:

2.4. Шаг 4: Сопоставление данных

Настраиваем сопоставление:

2.5. Запускаем интеграцию

3.1. Шаг 1 - Откуда

Выбираем событие успешного срабатывания интеграции, описанной выше.

3.2. Шаг 2: Инструменты

Данный шаг пропускаем.

3.3. Шаг 3: Куда

Удаляем привязку дела.

3.4. Шаг 4: Сопоставление данных

Настраиваем сопоставление:

3.5. Запускаем интеграцию

4.1. Шаг 1: Откуда

Забираем данные из Битрикс24 в момент события дела типа "Письмо". Дополнительным запросом указываем, что письмо берется из сделки.

4.2. Шаг 2: Инструменты

Используем API-запрос методом GET с урлом /crm.deal.get?ID={{source.OWNER_ID}}.

Используем инструмент Если-иначе по полю step1.result.COMPANY_ID.

Условие - ЧислоРавно, сравниваемое значение = 0, Результат при успешной проверке = 1, при неуспешной = 0.

Используем инструмент Если-иначе по полю step1.result.CONTACT_ID.

Условие - Логическое(Ложь), Результат при успешной проверке = 1, при неуспешной = 0.

Используем инструмент Если-Иначе по полю step1.result.COMPANY_ID && step1.result.CONTACT_ID. Условие - Логическое(Истина), Результат при успешной проверке = 1, результат при неуспешной проверке = 0.

Используем инструмент Проверка по полю step9. Условие - Логическое(Истина), Действие - прервать, если проверка пройдена.

Используем инструмент Если-Иначе по полю step12. Условие - Логическое(Ложь), Результат при успешной проверке = {{step1.result.COMPANY_ID}}, результат при неуспешной проверке = {{source.COMMUNICATIONS.0.ENTITY_ID}}.

Используем тип шага Если-Иначе по полю step12. Условие - логическое (ложь), Результат при успешной проверке = 4, результат при неуспешной проверке = 3.

Используем тип шага Если-Иначе по полю step2. Условие - Логическое (Ложь), Результат при успешной проверке = 4, результат при неуспешной проверке = 3.

Используем тип шага Если-Иначе по полю step4.CONTACT_ID. Условие - Число(Равно), сравниваемое значение - source.COMMUNICATIONS.0.ENTITY_ID. Результат при успешной проверке = 1, результат при неуспешной проверке = 0.

Используем инструмент Проверка по полю step12. Условие - Число(Равно), сравниваемое значение =1, действие - Прервать, если проверка пройдена.

4.3. Шаг 3: Куда

Выполняем привязку дела.

4.4. Шаг 4: Сопоставление данных

Сопоставляем данные:

4.5. Запускаем интеграцию

5.1. Шаг 1 - Откуда

Выбираем событие срабатывания описанной выше интеграции на успех.

5.2. Шаг 2: Инструменты

Используем API-запрос методом GET с урлом /crm.activity.binding.delete?activityId={{source.int7996.source.ID}}&entityTypeId=3&entityId={{source.int7996.source.COMMUNICATIONS.0.ENTITY_ID}}.

5.3. Шаг 3: Куда

Удаляем привязку дела.

5.4. Шаг 4: Сопоставление данных

Сопоставляем элементы.

5.5. Запускаем интеграцию

6.1. Выбираем событие Интеграция - Пропуск для интеграции, описанной в пункте 4.

6.2. Шаг 2: Инструменты

Используем проверку по полю source.int7996.step11. Условие - Логическое(Истина), сравниваемое значение =1, действие - продолжить, если проверка пройдена.

Используем API-запрос методом GET с урлом /crm.contact.company.items.get?id={{source.int7996.source.COMMUNICATIONS.0.ENTITY_ID}}.

Используем тип шага Для каждого по полю step2.result.

Используем API-запрос методом GET с урлом /crm.activity.binding.add?activityId={{source.int7996.source.ID}}&entityTypeId=4&entityId={{step3.COMPANY_ID}}.

Используем API-запрос методом GET с урлом /crm.activity.binding.delete?activityId={{source.int7996.source.ID}}&entityTypeId=2&entityId={{source.int7996.source.OWNER_ID}}.

6.3. Шаг 3: Куда

Удаляем привязку дела.

6.4. Шаг 4: Сопоставление данных

Сопоставляем данные:

6.5. Запускаем интеграцию

С помощью настроенных выше интеграций мы решили следующие задачи заказчика:

7.1. Дела типа Письмо были перенесены из сделок и контактов в компании (если они есть на портале). При этом дела, которые остаются в родительской сущности, удаляются, чтобы не дублировать информацию.

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

#пинол #пинкит #pinall #pinkit #bitrix24 #битрикс24 #amo #amocrm #амо #амоцрм #crm #црм #црмсистема #црм_система #внедрениецрм #интеграция #миграция #обмен #перенос