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

Откуда задача

Я позволю себе немного абстрагироваться от деталей задачи, которая мне попалась недавно. Но делать ее надо было в виде реализации workflow на платформе n8n. Сотрудник попросил создать процесс условной отправки SMS сообщений через внешний API-сервер, но рассылка конечная, имеет не более 3-х итераций и может на любой из итераций быть прекращена, если получатель отреагировал на сообщение. В сообщении отправляется персональная ссылка на анкету обратной связи после посещения шоурума. 

Для отправки по любому плану всяких сообщений персонально человеку любой системе нужен план, поэтому без отметок времени никак. Есть начальная отметка когда нужно создать такую коммуникацию - например, когда посетитель шоурума покинул место шоурума и менеджер где-то в CRM оставил отметку, что закончил показательные мероприятия. Далее, нужно взять эту дату и создать тот самый план регулярной коммуникации в виде отправки SMS посетителю (назовем его субъектом А).

План решения

Допустим, что временной план коммуникации с А должен быть такой:

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

• ID - уникальный идентификатор нашей родительской коммуникации.
• InformDate1 - дата первого напоминания по графику (допустим +2 дня от первой коммуникации).
• InformDate2 - дата второго напоминания по графику (допустим +5 дней от первой коммуникации).
• InformStatus1, InformStatus2, Stop - поля с булевым типом с первоначальным значением False.

Создаем workflow 

В n8n остается описать примерно такой процесс:

Schedule (10:00, каждый день)
    └→ SeaTable (активные записи)
        └→ Filter (сегодняшние даты и где есть False)
            └→ GetbyID (CRM)
                └→ Если Feedback уже есть?
                    ├→ Да → Stop (все флаги = true)
                    └→ Нет → Проверка статуса InformStatus1
                            ├─ InformStatus1=Нет → Отметить InformStatus1=true → SMS(1)
                            ├─ InformStatus1=Да, InformStatus2=Нет → Отметить InformStatus2=true → SMS(2)
                            └─ InformStatus1+InformStatus2=Да, Finish=Нет → Email (завершающее)
                                                               └→ Finish=true

Для тестирование можете выставить 1 минуту, секунду в планировщике и проверить работу логики. После 3-ей итерации по графику у вас должны быть закрыты все булевы переменные (True). При следующей выборке из таблицы запись, где есть все true будет вне поля зрения вашего wokflow.

Еще момент насчет проектирования wokflow. Описанная здесь логика будет содержать компоненты со сквозным проходом по каждому item поступающего на вход любого блока данных после фильтра. Если поставите блок Code для программной обработки данных, то вместо first().json..., last().json... используйте item.json... чтобы потоковые элементы обрабатывались, т.к. из таблицы расписания могут быть 2 и более записей на отправку уведомлений.

Я привел только одну рабочую идею реализации с конечной обработкой заданий по расписанию на базе n8n. Вы можете сделать круче, лучше, иначе.

Удачного решения ИТ задач.