Как связать CRM и задачи в Битрикс24: 7 сценариев автоматизации
Самый частый запрос к Битрикс24 звучит примерно так: «Сделка перешла на стадию — пусть робот поставит задачу юристу, а потом вернёт результат в карточку». В теории это пара кликов. В реальности сразу вылезают дубли, потерянные ID, смена дедлайнов и перенос файлов в смарт-процессы.
Мы собрали в одну статью семь рабочих сценариев связки CRM ↔ задачи. В каждом отдельно написано, что берётся стандартными роботами, а где без бизнес-процесса или REST не обойтись.
Почему связь должна быть явной
CRM-элемент — это бизнес-контекст: клиент, сумма, стадия. Задача — это поручение: исполнитель, дедлайн, результат. Не надо копировать всю карточку сделки в задачу. Достаточно понятного названия, нужных данных и ссылки на исходный элемент.
Главный технический ключ — ID задачи. Не название, не ссылка, а именно числовой ID. Иначе повторный переход на стадию создаёт второй, третий и пятый дубликат «Подготовить договор», и никто не понимает, какую из них закрывать.
Сценарий 1: задача на стадии
Самый устойчивый запуск — переход CRM-элемента на стадию. Робот проверяет условия, создаёт задачу, сохраняет её ID в поле CRM. Главная ловушка — повторный вход на стадию. Если сделку вернули назад и снова вперёд, появится вторая задача. Значит, перед созданием нужно смотреть на поле ID и заранее решать, что делать со старой задачей.
Сценарий 2: письмо или звонок
Пропущенный звонок и письмо с реквизитами — разные задачи. Сначала нужно классифицировать событие, а потом уже ставить поручение. Если ответственный зависит от очереди, темы или графика дежурств, штатный робот быстро обрастает костылями. Тогда удобнее бизнес-процесс или приложение.
Сценарий 3: название из CRM
Список из десяти задач «Обработать клиента» бесполезен. Хорошее название отвечает на два вопроса: что сделать и по какому объекту. Робот может подставлять поля CRM прямо в название и описание. Но не стоит пихать туда телефон, адрес и сумму — заголовок станет нечитаемым, а персональные данные разойдутся по уведомлениям.
Сценарий 4: статус и дедлайн обратно в CRM
Руководитель хочет видеть срок и статус задачи, не переходя в раздел задач. Робот «Получить информацию о задаче» читает данные по сохранённому ID и записывает их в служебные поля CRM. Но мгновенная фиксация каждого переноса дедлайна со старым и новым сроком — это уже не робот, а журнал, который нужно собирать отдельно.
Сценарий 5: роли из CRM
Исполнителя по договору берём из поля «Ответственный», наблюдателем назначаем менеджера. Важно разделять роли: ответственный, постановщик, наблюдатель. Если назначить всех ответственными «для надёжности», личная ответственность пропадает.
Сценарий 6: завершение задачи из CRM
Сделку отменили, а задача «Подготовить предложение» осталась висеть. Штатный робот завершения закрывает задачи, созданные роботами в выбранном CRM-контуре. Если нужно закрыть конкретную произвольную задачу по ID — проверяем бизнес-процесс, иначе приложение или REST.
Сценарий 7: смарт-процессы и файлы
Смарт-процесс как реестр заявок — удобная схема: элемент создаёт задачу, ждёт результата, переходит на следующую стадию. С файлами сложнее: исполнитель приложил файл к задаче, но автоматически скопировать его в пользовательское поле смарт-процесса можно не везде. Если перенос не критичен, проще оставить связь с задачей и дать доступ к нужному файлу.
Как не наломать дров
Сначала — одна воронка и один тип поручения. Проверяем: создание, ID, дубли, смена ответственного, перенос дедлайна, завершение, отмена. После этого подключаем остальные сценарии. Это дешевле и безопаснее, чем строить длинную цепочку, в которой ошибка всплывёт только на реальной сделке.
