Битрикс24 добавил фильтр по связям: как найти сделки, потерявшие контекст
В августовском обновлении CRM появился поиск записей с нужными связями и без них. Объясняю, как использовать его для проверки данных и не принять нормальную сделку за ошибку.

В этой статье
В CRM бывает странная ситуация: сделка есть, сумма указана, менеджер назначен — а быстро понять, откуда она взялась и с кем связана, не получается. Для поиска таких записей в Битрикс24 появился полезный фильтр. О нём рассказали в августовском обзоре обновлений, опубликованном в справке с датой 4 сентября 2026 года.
Фильтр умеет отбирать элементы, у которых есть или отсутствуют связи с другими типами записей. В официальных примерах — сделки без связанных лидов и сделки со связанными контактами. Возможность заявлена для всех типов элементов CRM и режимов просмотра.
Связь — это не просто похожий текст
Если имя покупателя написано в комментарии к сделке, человеку оно понятно. Но это ещё не означает, что сделка связана с карточкой контакта. Такая связь нужна системе, чтобы переходить между записями и собирать историю работы с клиентом.
Поэтому новое условие фильтра полезно как проверка структуры данных. Оно помогает найти записи, которые стоит рассмотреть внимательнее. Само по себе оно не определяет, правильно ли устроен весь процесс продаж.
Сделка без лида не обязательно потеряна
Я бы не начинала с массового исправления всех найденных записей. В одной компании сделки заводят после обработки лида, в другой — сразу из заказа. Во втором случае отсутствие связанного лида может быть нормой.
Сначала нужно описать ожидаемый маршрут. Например: заявка с сайта создаёт лид, после квалификации появляется сделка, к ней прикрепляется контакт. Вот для такого маршрута список сделок без лидов уже даёт понятную отправную точку для проверки.
Если же сайт сразу создаёт сделку и контакт, проверять нужно именно эту связь. Иначе можно потратить время на «ошибки», которых на самом деле нет, и пропустить настоящую проблему.
Как проверить интеграцию на нескольких записях
Выберите конкретный период и один источник обращений. Возьмите несколько найденных сделок и сравните их с исходными заявками: совпадают ли время, клиент и ответственный, есть ли карточка контакта, не создалась ли она повторно.
Отдельно посмотрите, когда должна возникать связь. Если она появляется только после ручного изменения стадии, важно выяснить, так задуман процесс или обмен срабатывает слишком поздно. Фильтр показывает следствие; причину всё равно придётся искать в настройках и журнале интеграции.
В заметках к проверке достаточно фиксировать идентификатор сделки, ожидаемую связь и фактический результат. Несколько точно описанных примеров помогут разработчику быстрее, чем сообщение «CRM опять не работает».
Что делать с найденными расхождениями
Сначала разделите их на реальные ошибки и допустимые исключения. Старые сделки, ручной ввод и тестовые обращения могут жить по другим правилам. Исправлять всё одним массовым действием без этой проверки я бы не стала.
Когда причина понятна, полезно повторить проверку на новых обращениях. Если исправить только старые карточки, но оставить прежний обмен, через неделю список снова наполнится.
У этого обновления нет эффектной витрины, зато есть понятное применение: находить разрывы в данных до того, как они испортят отчёт или заставят менеджера заново расспрашивать клиента. Начать можно с одной связи, которая действительно важна вашему процессу продаж.
In a CRM, you may encounter a strange situation: a deal exists with an amount and an assigned manager, yet it is difficult to quickly determine its origin or connections. Bitrix24 now offers a useful filter to locate such records. This feature was announced in the August update review published in the help center on September 4, 2026.
The filter can select items that have or lack connections to other record types. Official examples include deals without linked leads and deals with linked contacts. This capability is available for all CRM record types and viewing modes.
A connection is more than just similar text
If a buyer's name is written in a deal comment, it is clear to a person. However, this does not mean the deal is linked to a contact card. Such a link is required by the system to navigate between records and compile the client interaction history.
Therefore, the new filter condition serves as a check on data structure. It helps identify records that warrant closer inspection. By itself, it does not determine whether the entire sales process is correctly organized.
A deal without a lead isn't necessarily lost
I wouldn't start by mass-correcting all found records. In some companies, deals are created after lead processing, while in others, they are created directly from orders. In the latter case, the absence of a linked lead may be normal.
First, define the expected workflow. For example: a website form creates a lead; after qualification, a deal is generated and a contact is attached. For such a workflow, the list of deals without leads provides a clear starting point for verification.
If the website creates both the deal and the contact directly, you must verify that specific link. Otherwise, you may waste time on 'errors' that don't exist and miss the real issue.
How to verify the integration across multiple records
Select a specific period and one source of inquiries. Pick several found deals and compare them with the original requests: do the time, client, and responsible person match? Is there a contact card, and was it created again?
Separately, check when the link should appear. If it only occurs after a manual stage change, determine whether this is intentional or if the integration triggers too late. The filter reveals the symptom; the root cause must still be found in the settings and integration logs.
In notes for verification, record only the deal ID, the expected relationship, and the actual result. A few precisely described examples will help a developer resolve issues faster than a vague message like 'CRM is broken again.'
What to do with identified discrepancies
First, separate them into actual errors and acceptable exceptions. Old deals, manually entered records, and test inquiries may follow different rules. I would not recommend fixing everything with a single bulk action without this preliminary check.
Once the cause is understood, it is useful to re-run the verification on new inquiries. If you fix only the old cards but leave the data exchange unchanged, the list will fill up again within a week.
This update lacks a flashy showcase, but it offers a clear application: identifying data gaps before they corrupt reports or force managers to re-question clients. Start with a single relationship that is truly critical to your sales process.

Обсуждение0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.