Бизнес-процесс, сигнал от объекта, изменение; добавление информации о предыдущем значении, и доп.условие старта

В бизнес-процессах среди "начальных событий" наиболее часто используемым является "сигнал от объекта", из трех вариантов действий на которые должна осуществляться реакция: с вариантами "Создания" и "Удаления" - функционал фильтрации события на старте а также набор "входных" параметров (основываясь на практике использования) - достаточен, в силу специфики юзкейсов. А вот с действием "Изменение записи", по моему мнению, функционала немного не хватает для построения более линейной и "красивой логики", а так же покрытия большого количества типовых юзкейсов, в нем сильно не хватает функционала связанного с "ИЗМЕНЯЕМЫМ значением" 1) Было бы очень круто, среди условий старта по сигналу иметь не только блок проверки "После изменения запись должна соответствовать условиям" Но и блок проверки "Перед изменением запись должна соответствовать следующим условиям" Что позволило бы развивать юзкейсы связанные с изменением конкретных значений на конкретные значения (довольно часто вписывающиеся в требования бизнес-логики). А так же позволило бы избежать проблем связанных с реализацией кейса "при первичном заполнении ранее не заполненного поля", которые сплошь и рядом встречаются в бизнес-требованиях, и решать задачу приходится через введение дополнительных полей-флагов (булево) которое отражают факт выполнения логики обработки первичного заполнения. Устанавливая его в этом же вызове БП, чтобы в дальнейшем при изменении этого поля логика первичной инициализации уже не отрабатывала. (что есть суть - overhead в чистом виде и по БД и по архитектуре, Бритва Окама - негодует) 2) Так же было бы неплохо иметь ИЗМЕНЕННОЕ и ИЗМЕНЯЕМОЕ значение в виде стартовых параметров в сигнале БП, это позволило бы избежать как минимум одного побочного "Чтения данных" или "Если старое значение X а новое значение Y то... иначе...", а в некоторых случаях позволило бы развивать юзкейсы "Если новое значение конкретный X то..." прямо со старта процесса, что выглядит более линейным и логичным с точки зрения схематики. Я уже вижу сотню применений такой возможности на своих задачах. Хотелось бы услышать мнение сообщества по поводу моего предложения, Вам тоже не хватает подобной функциональности ?