Надо назначить по задаче на неизвестное количество согласующих (количество и состав определяются динамически).

в простом варианте можно попробовать https://docs.camunda.org/manual/7.11/reference/bpmn20/gateways/inclusive-gateway/

там ветки создаются по условию

в сложном варианте https://docs.camunda.org/manual/7.11/reference/cmmn11/

с практической точки зрения удобно в в том месте, где not approved создать конечное событие и по нему стартануть процесс реализации отказа. Как правило, точек отказа много, процедура отказа одинаковая: какое-нибудь письмо счастья и перевод заявки в статус "Отказано". И главное, что если пошел отказ, то дальше основной процесс уже не нужен.   Если нужно где-то фиксировать причину отказа, то удобно писать ее в имя конечного события, чтобы оно наглядно показывалось на схеме, и оттуда его парсить

Именно в задаче не сталкивался.
Делал подобное для CallActivity, в которую передавалась переменная с коллекцией идентификаторов исполнителей. Процесс исполнения создавался для каждого элемента коллекции. Незавершённые прерывались терминальным закрытием вызвавшего процесса.

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

костыльно, но рабоает, когда-то так реализовали

а можно пример самой bpm?

https://docs.camunda.org/manual/7.8/reference/bpmn20/tasks/task-markers/

Можно добавить выражение, которое будет вычисляться после каждой завершённой задачи и на основании результата схлопывать все.

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

Примерно так с испольованием только UserTask

Коллеги, не подскажите, как получить лейбл поля через REST API?

Из коробки никак

Жаль

Рест расширить изи

example @Path("/") public ctaskfieldslass TaskFieldsService { @GET @Produces(MediaType.APPLICATION_JSON) @Path("{taskId}") public String getFormFieldList(@Context HttpHeaders httpHeaders, @PathParam("taskId") String taskId) { ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine(); FormService formService = processEngine.getFormService(); TaskFormData taskFormData = formService.getTaskFormData(taskId); List<FormField> formFieldList = taskFormData.getFormFields(); System.out.println("Strike"); String json = JSON(formFieldList).toString(); return json; }

понятно. спасибо за ответ!

ребят, подскажите с областями видимости переменных. (ща большой вопросег будет)

есть вот такая схема.
Все блоки - обычные активити с джава классами.

эти классы создают некие локальные переменные. Так как класс один и тот же (для чтения клиентов например), то чтобы различать данные, в коде используется setVariableLocal и всё работает так как я ожидаю.

Но если хочу заменить синхронную сервисную таску GetUserList на асинхронную (ExternalTask) то у меня больше нет понятия VariableLocal, потому что при вызове метода Complete те переменные, котрые передаются - устанавливаются на уровне всего процесс инстанса.

таким образом, будут не 2 переменные с одним именем и разным значением в разном скоупе, а одна - с последним значением.