From dd2fa47555e253a1aff1a88c4a3f21a9b4a2f0c8 Mon Sep 17 00:00:00 2001 From: Dmytro Kostiuk Date: Mon, 4 Aug 2025 11:04:15 +0200 Subject: [PATCH] Remove Current Limitation and add Jumping from Current Activity to Itself --- .../application-logic/workflows/boundary-events.md | 4 ---- .../modeling/application-logic/workflows/jump-to.md | 8 ++++++++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md b/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md index cf7ecc577bc..c6da83cea07 100644 --- a/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md +++ b/content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md @@ -130,10 +130,6 @@ The list of variables is described below: * `$ParentTask` – the parent user task of the attached boundary event * `$CalledWorkflowInstance` – the parent Call workflow activity of the attached boundary event -## Current Limitation {#limitation} - -* The already-scheduled timer boundary event will not be cancelled when a new one is scheduled for the same boundary event definition. For example, if a workflow instance has a scheduled timer boundary event, and you make a manual jump from a [Multi-User Task](/refguide/multi-user-task/) to itself, or a jump from the parent activity to another activity earlier in the executed path that causes it to run a second time, the timer boundary event will be scheduled again while the original timer is still pending. When the original timer expires, the boundary event will be triggered and the new timer will be disregarded. This is a limitation that will be fixed in the future. - ## Read more * [Workflows](/refguide/workflows/) diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/jump-to.md b/content/en/docs/refguide/modeling/application-logic/workflows/jump-to.md index c7ff2b50824..097f47bd9b9 100644 --- a/content/en/docs/refguide/modeling/application-logic/workflows/jump-to.md +++ b/content/en/docs/refguide/modeling/application-logic/workflows/jump-to.md @@ -46,6 +46,14 @@ Jumping to other activities has a limitation in parallel splits and in boundary For more information about jumping rules in a boundary event path, see the [Jump Rules](/refguide/workflow-boundary-events/#jump-rules) section in *Boundary Events*. +## Jumping from Current Activity to Itself + +It is possible to jump from an active [Multi-user task](/refguide/multi-user-task/) back to itself. When this occurs, the following behavior applies: + +* All individually selected outcomes are reset. +* Targeted and assigned users are cleared, and user targeting will be executed again. +* Any existing timer boundary events that have already been scheduled will continue running and will not be canceled. After the jump is executed, the same boundary events will be scheduled again. As a result, duplicate timer boundary events may be scheduled and waiting for their timers to expire at the same time. These duplicate events will remain pending until the originally scheduled events expire, at which point the newly scheduled ones are automatically aborted. + ## Read More * [Generate Jump-To Options](/refguide/generate-jump-to-options/)