Внедрение · действующая автоматизация
Изменение активной автоматизации: что произойдёт с ожидающими запусками
Сократить ожидание с двух суток до одних кажется простой правкой. Но часть заявок уже провела в задержке больше суток: после сохранения они могут сразу перейти к действию. До изменения выясните, какие запуски затронуты и что конкретная система делает при выключении, редактировании и повторном включении.
Какой результат перехода нужен владельцу
В сервисной компании правило создаёт внутреннюю задачу по заявке, ждёт заданное время и при незавершённой работе направляет её руководителю. Команда хочет изменить ожидание только для новых заявок. Это решение отличается от просьбы пересчитать сроки всех уже ожидающих: одинаковый новый рисунок workflow может дать разные последствия.
Общий порядок ввода версии разобран в руководстве по обновлению регламентов. Здесь проверяем узкую техническую границу: что произойдёт с конкретным выполняющимся запуском, его таймером и ещё не выполненным действием. Не предполагаем, что переключатель «выключено» сохраняет всё на прежнем шаге.
До настройки владелец выбирает судьбу существующих запусков: закончить по прежним условиям, применить согласованное изменение либо передать отдельные случаи сотруднику. Если старое действие уже нельзя выполнять, ожидание его естественного завершения не подходит. Способ остановки должен быть проверен до рабочего изменения.
Разделите запись клиента, запуск и результат шага
Одна заявка может проходить несколько разных сценариев. У каждого запуска нужны собственный идентификатор, связанная заявка, применённое правило, момент входа и текущий шаг. У созданной задачи есть отдельный ID. Номер клиента не заменяет эти связи.
Снимок перед изменением должен показывать как минимум ожидающих в задержке, готовых к следующему действию, уже завершённых и случаи с неизвестным результатом. Отдельно найдите подходящие записи, которые ещё вообще не входили в сценарий. Это не одна общая «очередь» с одинаковым способом возобновления.
Сохраните старое ожидаемое время выхода и основание его расчёта. Обновив экран до нового значения, легко потерять возможность объяснить, почему задача вдруг появилась раньше. Момент снимка и изменения важен: между ними запуск мог самостоятельно перейти дальше.
Выключение может пропускать шаги, а не замораживать их
По текущей справке HubSpot выключенный workflow не принимает новые записи, но уже участвующие продолжают проходить ветвления и задержки. Обычные действия пропускаются; последующее включение не исполняет пропущенное автоматически. Это поведение конкретного продукта, а не универсальное определение паузы. HubSpot: последствия выключения.
Поэтому вопрос администратору должен звучать предметно: «Если таймер закончится во время остановки, где окажется эта заявка и как мы найдём невыполненное действие?» Ответ «сценарий выключен» не объясняет судьбу обещания клиенту.
Перед остановкой проверьте отдельным тестом запрет новых входов, сохранение текущих ожиданий и запрет внешних действий. Это три разных свойства. Не меняйте рабочие права или настройки рассылки наугад, пытаясь получить недокументированную паузу; при отсутствии подходящего управления нужен согласованный ручной порядок.
Пример: правка задержки затрагивает прежние заявки
Все записи вымышлены. Контрольный момент — 12 октября 2026 года, 12:00 UTC. Сценарий использует непрерывное ожидание 48 часов без исключения выходных и без дополнительного расписания действий. Время отсчитывается от фактического входа в шаг задержки.
- A вошла 11 октября в 16:00: прошло 20 часов, прежний выход 13 октября в 16:00.
- B вошла 11 октября в 06:00: прошло 30 часов, прежний выход 13 октября в 06:00.
- C уже завершила сценарий; её задача руководителю существует и имеет подтверждённый ID.
- D дошла до создания задачи, но результат последней попытки пока неизвестен.
- E соответствует условиям отбора, однако никогда не участвовала в этом сценарии.
В HubSpot изменение длительности задержки пересчитывает ожидание уже находящихся в ней записей с учётом прошедшего времени. Удаление задержки выпускает ожидающих к следующему шагу. HubSpot: изменение задержки.
Если в такой модели заменить 48 часов на 24, A останется ждать четыре часа и выйдет 12 октября в 16:00. B уже ждала дольше 24 часов и выйдет из задержки сразу после применения изменения. Это выход к следующему шагу, а не доказательство мгновенного создания задачи: дальше ещё действуют проверки и фактическое выполнение.
Такой результат не соответствует исходному намерению «новое ожидание только для новых заявок». Для него нужен подтверждённый способ отделить новые запуски от A и B. Копия схемы сама по себе этого не обеспечивает: обе схемы могут принять одно событие. Поддержку раздельных версий или иного перехода проверяют в выбранной системе.
Старые совпадения и повторный вход проверяются отдельно
Включение нового правила может затронуть и E, хотя по ней сегодня ничего не произошло. HubSpot при запуске предлагает выбор между уже подходящими записями и будущими совпадениями; для сценариев по расписанию отказ от немедленного включения старых записей не исключает их вход при следующем запуске расписания. HubSpot: активация и существующие записи.
Составьте проверяемый список E-подобных случаев и решите, нужны ли по ним действия сейчас. Давняя дата завершения услуги не должна превращаться в новое событие только из-за публикации правила. Массовое включение старой базы является отдельным решением с собственной областью проверки.
C нельзя снова запускать с начала лишь потому, что в новой версии появилась полезная правка. Сначала выясните, требуется ли вообще дополнительная работа. D нельзя считать невыполненной по одному тайм-ауту: найдите результат по заявке и ключу действия. Общие правила такого восстановления уже описаны в разборе цепочек Flow.
Сверьте переход по запускам, а не по зелёному индикатору
Для A и B запишите выбранную политику и фактическое следующее время. Для C сохраните завершение и ссылку на существующую задачу. Для D назначьте проверяющего результат. Для E зафиксируйте отдельное решение о допуске в новый сценарий. У каждой записи должен быть объяснимый итог, даже если итогом стало отсутствие нового действия.
Если остановка уже привела к пропуску шага, подготовьте перечень пропущенных действий и проверьте их актуальность. Выполнение всего процесса заново способно повторить успешно завершённые ранние шаги. Когда нет поддерживаемого продолжения с нужного места, оформите только действительно оставшуюся работу по согласованному ручному пути.
Проверьте состояние клиента непосредственно перед любым сообщением: за время ожидания вопрос мог решиться. Отбор и отмена follow-up рассматриваются отдельно. Здесь важно, чтобы смена версии не стерла основание уже выполненного шага и не спрятала пропущенный.
Небольшой тест перед рабочей правкой
- Сохранён список текущих запусков с шагами, временем входа и результатами.
- Тест выключения показывает судьбу записи, чей таймер истекает в период остановки.
- Уменьшение задержки проверено для записи моложе и старше нового интервала.
- Выход из ожидания отдельно отличается от успешного действия.
- Завершённая C не получает копию задачи, неизвестная D не повторяется вслепую.
- Существующая E и новое событие проверены отдельно, включая запуск по расписанию.
- При двух версиях исключены одновременно двойной вход и потеря новых событий.
- После перехода сверены фактические задачи и оставшаяся работа, а не только состояние переключателя.
Для SABSUS Flow подтвердите доступ к истории шагов и конкретное поведение активных запусков при изменении. Возможность заморозки, сохранения прежней версии, переноса таймеров или продолжения с произвольного шага здесь не заявляется.
Обновление завершено, когда понятна судьба каждого затронутого запуска и не потеряно ни одно действующее обязательство. Сохранённая новая схема — только часть этой проверки.