Как создавать и обновлять задачи из CRM: 7 сценариев автоматизации в Битрикс24

Менеджер переводит сделку на стадию «Подготовить договор», и юристу нужна задача. Клиент присылает письмо, после которого сотрудник должен уточнить детали. Производственный заказ переходит в работу, и в смарт-процессе пора поставить поручение исполнителю. Во всех трёх случаях задача рождается из события в CRM, а результат её выполнения должен вернуться в карточку.

На первой демонстрации такая автоматизация выглядит просто: робот создал задачу, сотрудник её закрыл. В рабочем процессе быстро появляются вопросы. Как не создать дубль? Где хранить ID задачи? Что произойдёт после переноса дедлайна? Можно ли закрыть конкретную задачу, а не все задачи со стадии? Как перенести итоговый файл в смарт-процесс?

Здесь разобрана автоматизация задач из CRM в Битрикс24: создание поручения из события CRM, сохранение ID, возврат статуса и завершение задач своего контура. Просмотр и фильтрация уже связанных задач описаны в материале «Быстрые фильтры задач в карточке сделки», обмен между порталами — в статье «Межпортальные задачи Битрикс24», а приёмка результата — в разборе контроля задачи после завершения. Эти три темы здесь не рассматриваются. Возможности автоматизации зависят от тарифа и текущей редакции Битрикс24, поэтому перед запуском схему стоит собрать на тестовой воронке. Базовый набор действий описан в официальной справке о роботах и триггерах для задач и в отдельной статье об управлении задачами из CRM.

Как связать CRM и задачи в Битрикс24

Связь должна быть явной. CRM-элемент хранит бизнес-контекст: клиента, сумму, стадию, заказ, обращение или внутреннюю заявку. Задача хранит поручение: исполнителя, постановщика, дедлайн, описание, чек-лист, участников и результат работы. Не стоит копировать в задачу всю карточку сделки. Достаточно дать сотруднику понятное название, нужные данные и ссылку на исходный элемент.

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

Практичная модель содержит в CRM несколько служебных полей:

• ID связанной задачи;
• дата создания задачи;
• текущий дедлайн задачи;
• последний известный статус;
• дата завершения;
• при необходимости ID элемента смарт-процесса или другого связанного объекта.

Служебные поля лучше вынести в отдельный раздел карточки и, если настройки прав конкретной сущности и тарифа это позволяют, ограничить их ручное редактирование. Иначе значения придётся дополнительно проверять перед запуском автоматизации. Если одна сделка порождает несколько поручений, одного поля «ID задачи» уже мало. Нужен либо отдельный набор полей для каждого типа задачи, либо реестр связей в смарт-процессе. Строка с ID через запятую работает до первой попытки найти, какая из пяти задач относится к договору, а какая — к оплате.

Матрица автоматизации CRM ↔ задачи

Событие	Действие	Как хранится связь	Ограничение
Элемент CRM перешёл на стадию	Создать задачу	ID созданной задачи в поле CRM	Нужна защита от повторного входа на стадию
Пришло письмо или зарегистрирован звонок	Поставить задачу ответственному	ID задачи плюс ID CRM-элемента	Нетипичная маршрутизация по каждому делу может потребовать бизнес-процесс или приложение
Создаётся задача из CRM	Сформировать название и описание из полей карточки	ID задачи; значения берутся из CRM	Подстановка значений при создании доступна штатно
После создания изменились поля CRM	Обновить название существующей задачи	Сохранённый ID задачи	Действие бизнес-процесса надо проверить; универсальный вариант — приложение или REST
Наступил контрольный момент	Получить дедлайн и статус задачи	По сохранённому ID	Мгновенная реакция на каждый перенос дедлайна может потребовать доработку
Сменился ответственный или стадия CRM	Назначить нужного исполнителя	ID задачи и правила ролей	Произвольная смена постановщика готовой задачи обычно выходит за рамки простой цепочки роботов
Сделка завершена или отменена	Завершить связанную задачу	Штатная связь робота либо сохранённый ID	Штатный робот закрывает задачи из заданного контура, а не любую задачу по произвольному ID
Задача завершена с результатом	Обновить смарт-процесс, записать статус или файл	ID задачи + ID элемента смарт-процесса	Копирование вложения в пользовательское поле часто требует бизнес-процесса, приложения или REST

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

Сценарий 1. Создание задачи при переходе сделки или лида на стадию

Самый устойчивый запуск — переход CRM-элемента на определённую стадию. Например, сделка попала в «Договор на подготовке», и робот ставит задачу юристу. В настройках задают название, описание, ответственного, постановщика, участников, дедлайн, чек-лист, проект или поток. Поля карточки можно подставить в текст задачи. Возможности самого действия «Поставить задачу» перечислены в справке по роботам для задач.

Штатно собирается базовая цепочка:

1. робот проверяет условия запуска;
2. создаёт задачу;
3. сохраняет её ID в поле CRM;
4. следующий робот пишет дату создания или служебную отметку.

Главная ловушка — повторный вход на стадию. Сотрудник вернул сделку назад, затем снова передвинул её вперёд, и появилась вторая задача. Перед созданием нужно проверять поле ID и заранее решить, что делать с прежним поручением. Иногда его следует оставить, иногда завершить, а иногда создать новое как отдельный цикл работы.

Что штатно: создание задачи на стадии, заполнение основных параметров, подстановка CRM-данных, связь с карточкой.

Где понадобится расширение: несколько задач по динамическому списку исполнителей, сложная проверка дублей, повторный запуск с версионностью. Это можно собрать бизнес-процессом; при большой нагрузке и нестандартных правилах удобнее приложение или REST-интеграция.

Сценарий 2. Задача после входящего письма или звонка в CRM

Звонок и письмо сами по себе ещё не определяют поручение. Пропущенный звонок требует перезвонить, письмо с реквизитами — обновить карточку, а рекламная рассылка не требует ничего. Поэтому правило начинается не с действия «создать задачу», а с классификации события.

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

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

Что штатно: поставить задачу после проверяемого изменения CRM-элемента, назначить ответственного, задать относительный дедлайн и связать задачу с карточкой.

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

Сценарий 3. Название задачи из полей CRM

Список из десяти задач «Обработать клиента» бесполезен. Хорошее название отвечает хотя бы на два вопроса: что сделать и по какому объекту. Например: «Проверить договор — Компания — Сделка» или «Перезвонить по обращению — Контакт».

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

Шаблон стоит проектировать с запасным вариантом. Если поле «Компания» пустое, можно подставить контакт или номер элемента. Если тема письма меняется, лучше хранить её в описании, а заголовок оставить стабильным. Для пользователя полезен читаемый текст, для автоматизации — ID.

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

Что штатно: сформировать название и описание при создании из полей CRM.

Где понадобится расширение: переименовать существующую задачу по сохранённому ID, применить сложные условия и запасные шаблоны. Возможность конкретного изменения надо проверить в доступных действиях бизнес-процесса; универсальный вариант реализуется через REST.

Сценарий 4. Дедлайн и статус задачи возвращаются в CRM

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

Робот «Получить информацию о задаче» получает поля конкретной задачи и передаёт их следующим действиям. Такой подход описан в официальной статье об управлении задачами из CRM. Если задача создана на другой стадии, её ID заранее сохраняют в карточке и используют позднее.

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

Перенос дедлайна — отдельное событие. Периодическая проверка через роботов даёт снимок состояния, но не всегда ловит изменение сразу. Если CRM должна в тот же момент фиксировать старый и новый срок, причину переноса и автора изменения, потребуется бизнес-процесс, приложение или обработчик REST-события. Историю лучше хранить отдельными записями, а не перезаписывать одним полем.

Что штатно: прочитать задачу по ID, записать текущий срок и статус в CRM, отреагировать на статус связанной задачи.

Где понадобится расширение: журнал всех переносов, мгновенная реакция на изменение срока, эскалация по сложному календарю и учёт рабочего времени.

Сценарий 5. Ответственный и постановщик зависят от CRM

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

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

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

Что штатно: задать постановщика, ответственного и участников в момент создания; использовать значения CRM, доступные в настройках робота.

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

Сценарий 6. Завершение связанной задачи из CRM

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

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

Не следует считать этот робот универсальной командой «закрыть любую задачу по номеру». Если процесс должен завершить одну произвольную задачу, найденную по ID, сначала проверяют доступные действия бизнес-процесса. При отсутствии подходящего действия используют приложение или REST. Перед закрытием полезно проверить статус: завершённую задачу не трогать, а просроченную активную завершать только по явному правилу.

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

Что штатно: завершить задачи, созданные роботами в заданном CRM-контуре.

Где понадобится расширение: закрыть конкретную внешнюю или произвольную задачу по ID, записать причину, проверить дополнительные условия, обработать ошибку прав.

Сценарий 7. Задачи, смарт-процессы и файлы результата

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

Для устойчивой связи храните оба идентификатора:

• в смарт-процессе — ID задачи;
• в CRM-поле или отдельном реестре связей — ID элемента смарт-процесса; если ID дублируют в задаче, заранее определяют поддерживаемое место хранения и права доступа к нему.

Тогда завершение задачи можно сопоставить с нужной заявкой, а изменение смарт-процесса — с нужным поручением. Искать элемент по названию нельзя: названия повторяются и меняются.

С файлами граница штатных возможностей особенно заметна. Исполнитель может приложить файл к задаче или оставить результат в комментарии. Но автоматическое копирование конкретного вложения в пользовательское поле смарт-процесса требует определить, какой файл считать итоговым, кто имеет к нему доступ и что делать с новой версией. Простая связь с задачей оставляет файл доступным в исходном месте. Физический перенос или копирование часто собирают бизнес-процессом, приложением или REST.

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

Что штатно: создать задачу из смарт-процесса, связать объекты, читать статус задачи, менять элемент по известному ID.

Где понадобится расширение: двусторонний обмен без заранее сохранённых ID, выбор итогового вложения, копирование файла в поле смарт-процесса, версия и журнал ошибок.

Как спроектировать автоматизацию задач из CRM

Шаг 1. Зафиксировать событие и границу процесса

Опишите одно стартовое событие: переход на стадию, заполнение поля, регистрация обращения, создание элемента смарт-процесса. Формулировка «когда что-то поменялось» слишком широкая. Рядом укажите события, которые не должны запускать задачу.

Шаг 2. Описать одну задачу как данные

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

Шаг 3. Спроектировать ID и защиту от дублей

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

Шаг 4. Разделить штатную и дополнительную логику

Сначала соберите короткую цепочку из подтверждённых действий: создать задачу, сохранить ID, получить статус и, если задача входит в поддерживаемый CRM-контур, завершить её штатным роботом. Сложную маршрутизацию, журналы переносов и работу с файлами добавляйте после проверки основы. Общие принципы настройки автоматизации CRM собраны в справке Битрикс24.

Шаг 5. Определить ошибки и ручной выход

Что делать, если сотрудник уволен, у робота нет прав, ID пуст, задача удалена, файл недоступен или действие запустилось повторно? Хорошая схема не молчит: пишет понятную служебную отметку, уведомляет администратора процесса и оставляет карточку в состоянии, из которого можно продолжить вручную.

Тест-кейсы для связи CRM и задач

Проверка под администратором мало что доказывает. Нужны обычные учётные записи и разные роли.

Тест	Действие	Ожидаемый результат
Первичное создание	Перевести тестовую сделку на целевую стадию	Создана одна задача, заполнены название, роли и дедлайн, ID записан в CRM
Повторный вход	Вернуть сделку и снова перевести на стадию	Сработало согласованное правило: дубль не создан либо создан новый цикл с отдельной связью
Пустое поле	Создать задачу без компании или темы	Заголовок остаётся понятным, используется запасное значение
Смена ответственного	Передать CRM-элемент другому сотруднику	Исполнитель задачи меняется или остаётся прежним строго по правилу сценария
Перенос дедлайна	Изменить срок активной задачи и запустить настроенную контрольную проверку	После контрольного запуска CRM получает актуальный срок; мгновенная фиксация и история переноса проверяются только в расширенной схеме
Завершение задачи	Закрыть связанную задачу	CRM-триггер меняет только нужный элемент и только при совпадении фильтра
Закрытие CRM	Завершить или отменить сделку	Закрывается правильная задача; завершённые и чужие задачи не затронуты
Ошибочный ID	Подставить несуществующий ID	Процесс фиксирует ошибку и не меняет другой объект
Недостаток прав	Запустить цепочку в сценарии обычного пользователя	Для каждого действия зафиксирован и проверен фактический контекст выполнения; задача и файл доступны только требуемым ролям, а нехватка прав приводит к контролируемой ошибке
Файл результата	В расширенной схеме завершить задачу с двумя вложениями	По настроенному правилу выбирается один итоговый файл и проверяются права; если копирование не реализовано, в смарт-процессе остаётся только согласованная ссылка на исходный контекст

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

Типичные ошибки в автоматизации CRM-задач

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

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

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

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

Пятая — переносить файлы без правил версий и доступа. В результате в карточке оказывается черновик, а финальный документ остаётся в комментарии к задаче, который видит не каждый участник процесса.

FAQ по задачам из CRM в Битрикс24

Можно ли создать задачу из сделки без программирования?

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

Зачем хранить ID задачи в CRM?

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

Где хранить несколько ID задач по одной сделке?

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

Может ли завершение задачи передвинуть сделку на другую стадию?

Да, для связанной задачи используют CRM-триггер по её статусу. Фильтры обязательны, если с карточкой связано несколько задач: иначе сделка может перейти на стадию после закрытия не того поручения.

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

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

Можно ли закрыть любую задачу по её ID штатным CRM-роботом?

Штатный робот завершения рассчитан на задачи, созданные роботами в выбранном CRM-контуре. Для произвольной задачи по сохранённому ID нужно проверить доступные действия бизнес-процесса; если подходящего нет, используют приложение или REST.

Как передать файл из задачи в смарт-процесс?

Самый простой вариант — сохранить связь с задачей и оставить файл в исходном контексте. Если файл должен оказаться в отдельном поле смарт-процесса, задают правило выбора итоговой версии, проверяют права и собирают перенос бизнес-процессом, приложением или REST.

Выводы: когда автоматизировать задачи из CRM

Штатных роботов хватает, когда задача создаётся на понятной стадии, получает данные карточки, сохраняет ID, а CRM позже читает её статус или завершает задачи своего контура. Такая схема остаётся прозрачной для администратора и не требует лишней разработки.

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

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