Триггер по дате и времени

При настройке автоматизации в Битрикс24 через роботов с отложенным запуском (при всём уважении к мощи роботов) часто возникают сложности, которые мешают выстроить бесперебойный процесс:

1. Отсутствие даты на момент перехода в стадию
   Если в поле ещё не указана дата, робот не может рассчитать время срабатывания — элемент «зависает» на стадии, хотя должен двигаться дальше по процессу.
   Можно задать обязательность поля для перехода в стадию, но не всегда это удобно, а иногда приходится добавлять целую стадию для контроля ввода даты.

2. Изменение даты после запуска робота
   Когда значение в поле корректируется, уже запущенный робот продолжает работать по первоначальным параметрам. Результат: элемент перемещается не в тот момент, когда нужно, а по устаревшему расписанию.
   Например, мы настроили обязательность заполнения даты при переходе в стадию. Сотрудник для переключения стадии указал какую-то дату. А позже уточнил у клиента и внёс уже корректную.
   Робот уже запустился и сработает именно в какую-то дату.

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

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

Как это работает

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

Ключевые особенности

Универсальность полей
Поддержка всех типов полей с датой:

• дата (DD.MM.YYYY);
  
• дата и время (DD.MM.YYYY HH:MM);
  
• множественные даты (триггер сработает при наступлении одной из указанных дат);
  
• учёт часовых поясов.
  

Гибкие условия срабатывания
Настраивайте триггеры на:

• точную дату и время;
  
• интервал до события (за N минут/часов/дней до указанной даты);
  
• интервал после события (через N минут/часов/дней после указанной даты).
  

Добавляйте в настройках триггера в воронке условия срабатывания в зависимости от других полей элемента.

Отслеживание изменений
Если дата в поле редактируется, триггер пересчитывает время срабатывания автоматически. Нет риска «зависших» элементов или необоснованных переходов.

Отсутствие жёсткой привязки к стадиям
Триггер срабатывает независимо от текущей стадии элемента (но проверку стадии при необходимости можно задать в настройках триггера в воронке).

Как настроить?
Создание триггера

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

• Добавьте триггер в воронку на нужную стадию
  

• При необходимости настройте дополнительные условия срабатывания
  

Управляйте активностью триггеров
Если триггер временно не нужен, можно деактивировать его в настройках по кнопке "Редактировать".
Триггер останется в воронках, но не будет срабатывать.



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

Ограничения

• Максимальное количество триггеров на сущность — не ограничено.
  
• Точность срабатывания триггера — 5 минут.
  
• Поддержка часовых поясов.
  Приложение работает по стандартному времени портала.
  Если сотрудники находятся в разных часовых поясах и могут указывать в полях своё локальное время, рекомендуем включить в настройках полей учёт часовых поясов.
  Иначе, если сотрудник в Иркутске укажет время 17:00, а стандартный часовой пояс портала -- Москва, триггер сработает в 17:00 по московскому времени.
  Для проверки в настройках приложения выведены часы, которые отображают текущее стандартное время портала.
  
• Триггеры не сработают задним числом.
  Например, если сейчас 12:00 и триггер должен сработать в точное время, а сотрудник поменял значение поля с 13:00 (триггер ждал этого времени) на 11:00, то триггер в 11:00 уже не сработает.
  

Пример использования

Сценарий: автоматизация напоминания о продлении договора.

• В сделке есть поле "Дата окончания договора".
  
• Настроен триггер: за 3 дня до даты → переход в стадию "Продление договора".
  
• Если менеджер не продлил договор, сделка перейдёт в соответствующую стадию за три дня до окончания договора.
  
• Если менеджер самостоятельно продлил договор на год и обновил дату окончания договора, триггер сработает только на следующий год.
  

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

Сценарий: заселение гостя в отель.

• В сделке есть поля "Дата заезда" и "Дата выезда".
  
• Настроен триггер: за 2 дня до даты → переход в стадию "Заезд через 2 дня".
  
• Настроен триггер: в день заезда → переход на стадию "Заезд".
  
• Настроен триггер: в день выезда → переход на стадию "Выезд".
  
• Если дата заезда изменилась после бронирования, переходы по стадиям сработают всё равно корректно.
  
• Если дата выезда изменилась после заселения, переход в стадию Выезд также сработает уже в новую дату.
  

Пример настроек для такого сценария:
В сделке созданы поля "Дата заезда" и "Дата выезда".


В воронке добавлены стадии "Заезд через 2 дня", "Заезд сегодня" и "Выезд сегодня".


Задача сделать так, чтобы сделки попадали в стадию "Заезд через 2 дня", клиенту отправлялось напоминание о заезде, а сотрудники видели к каким заездам необходимо подготовиться.
В день заезда утром сделка должна перейти в стадию "Заезд сегодня".
А в день выезда сделка должна утром перейти в стадию "Выезд сегодня".

Для этого в приложении создаём триггеры:


Для триггера "Выезд сегодня" выбираем поле "Дата выезда". Указываем условие срабатывания "за 4 часа до даты".
Выезд в 14:00, значит триггер переместит сделку в стадию выезда в 10:00.



По тому же принципу создаём два оставшихся триггера.

Для триггера "Заезд сегодня" выбираем поле "Дата заезда". Указываем условие срабатывания "за 7 часов до даты".
Заезд в 17:00, значит триггер переместит сделку в стадию "Заезд сегодня" в 10:00.

Для триггера "Заезд через 2 дня" выбираем поле "Дата заезда". Указываем условие срабатывания "за 55 часов до даты".
Можно было бы указать условие просто "за 2 дня до даты", но тогда сделки перемещались бы за два дня, но в 17:00.
Мы хотим, чтобы это происходило за два дня и утром, поэтому указываем именно "за 55 часов".

Созданные триггеры теперь доступны в настройках автоматизации воронки.




Добавляем триггеры на соответствующие стадии.



Теперь сделки будут перемещаться по стадиям в соответствии с данными в полях "Дата заезда" и "Дата выезда".

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

Гибкость: нет привязки к «стартовой» стадии, в отличие от роботов.

Масштабируемость: неограниченное количество условий без перегрузки бизнес‑процессов.

Приложение интегрируется в существующую конфигурацию Битрикс24 без изменения текущих процессов. Настройка занимает 10–15 минут, а эффект заметен с первого дня использования.