я пробовал с InstanceID, c Execution ID, и прочее....
Вот как создаются Executions в камунде на этой схеме

каждая обведенная область - отдельный Execution со своим скоупом переменных

Кстати не гарантируется, что именно так

Могут меняться местами в ветках

а, там еще и ExternalTasks, которые получают свой екзекушн

да. но идея та же. в корне отличается от того, чтобы я хотел

Не верю, что задача именно так стоит :) в чем прикол делать так?

ща попробую описать. Займет чутка времени

Представь, что каждый блок - предопределённый фильтр на множество элементов.

Джава класс в этих блоках - один и тот же, отличается только параметрами (ИД фильтра и его параметры)

Соответственно, предполагается, что я заранее придумал с пару десятков фильтров, и потом переставляя и комбинируя блоки - по разному их применяю.

Предполагается, что можно передавать выход одного фильтра на вход другого.

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

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

у меня железобетонное убеждение, что мы пытаемся микроскопом гвозди заколачивать =((((

. похоже на цепочку ответственности

Паттерн такой

Так себе бизнес процесс, если честно

А бизнесовая задача какая?

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

Это получается штука без состояния?

что ты имеешь ввиду?

потом разумеется сохраняются и сообщения, котрые были посланы, и кому, перед посылкой - аппрув от менеджера

просто у меня получается что каждый следующий активити должен знать из какого активити пришел поток выполнения.