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/)