Change Boundary Event Type

content/en/docs/refguide/modeling/application-logic/workflows/boundary-events.md

@@ -75,6 +75,23 @@ To configure the properties of a boundary event, double-click the event to open
 
 When a boundary event is added to an ongoing activity, any workflow instances currently executing that activity will schedule the new boundary event accordingly. The only exception occurs when an ongoing boundary event is removed from the ongoing activity, the workflow is redeployed, and then the removal is reverted. In this case, the re-added boundary event will not be scheduled.
 
+### Changing Boundary Event Type
+
+You can change the type of existing boundary event via the context menu, without having to delete and re-add it. To do so:
+
+1. Right-click the boundary event to open its context menu.
+2. Click **Change event**.
+3. Select one of the available options:
+
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu-change-event.png" alt="Changing boundary event type through context menu" width="450" >}}
+
+You can convert between any of the following supported boundary events:
+
+* Notification (Interrupting)
+* Notification (Non-Interrupting)
+* Timer (Interrupting)
+* Timer (Non-Interrupting)
+
 #### Implications of Changing the Interrupting Behavior {#event-type-change}
 
 For an existing boundary event, when you change its interrupting behavior from non-interrupting to interrupting or vice versa, you will be presented with a warning dialog. For example, when you change a boundary event from non-interrupting to interrupting, you will see the following warning dialog:
@@ -90,6 +107,12 @@ After you confirm the change:
 
 Boundary events are re-created upon interrupting behavior change because in-place conversion can result in invalid states. An interrupting boundary event must abort its parent activity when triggered, meaning an activity cannot have more than one active interrupting boundary event. Converting an already-triggered non-interrupting boundary event to interrupting in place violates this rule: the parent activity remains in progress, resulting in an interrupting boundary event whose parent is never aborted. Conversely, converting an already-triggered interrupting boundary event to non-interrupting in place leaves it active on an already-aborted parent activity, contradicting the rule that a non-interrupting boundary event must not abort its parent.
 
+#### Implications of Changing the Boundary Event Type
+
+When the type of an ongoing **non-interrupting** boundary event is changed (for example, from Timer to Notification), this causes a partially resolvable [Current Activity Moved out of Path](/refguide/workflow-versioning/#current-activity-moved-out-of-path) conflict. This only applies to non-interrupting boundary events and is an exception due to technical limitations.
+
+For more information on how to deal with such conflicts, see [Workaround for Non-resolvable and Partially Resolvable Conflicts](/refguide/workflow-versioning/#workaround-for-non-resolvable-and-partially-resolvable-conflicts).
+
 ### Rearranging Boundary Events
 
 You can rearrange boundary events in the following ways:

content/en/docs/refguide/modeling/application-logic/workflows/workflow-versioning.md

@@ -157,6 +157,8 @@ If a currently running workflow instance is executing an activity that is moved
 
 Conversely, moving an activity from a parent path into a nested scope, such as a boundary event path or a sub-process, can also prevent the workflow from progressing. In these scenarios, the Workflow Engine cannot guarantee the integrity of the execution flow. This can result in the workflow instance remaining stuck in the **In Progress** state indefinitely, preventing it from ever reaching a completed state.
 
+This conflict can also occur when the type of an ongoing non-interrupting boundary event is changed. For more information, see [Changing Boundary Event Type](/refguide/workflow-boundary-events/#changing-boundary-event-type).
+
 You can do one of the following:
 
 * The workflow can be aborted, for example, by using the **DefaultWorkflowAdmin** page in the Workflow Commons.
@@ -210,6 +212,8 @@ You can do one of the following:
 
 When an app developer adds one or more activities in a workflow (or moves one or more activities to an earlier position in the flow), workflow instances that have already passed that point in the flow will not execute these activities. This may not necessarily be a problem, but it is possible that activities that have not been executed yet depend on new activities.
 
+This conflict can also occur when the type of an ongoing boundary event is changed. For more information, see [Changing Boundary Event Type](/refguide/workflow-boundary-events/#changing-boundary-event-type).
+
 You can do one of the following:
 
 * The workflow can be aborted, for example, by using the **DefaultWorkflowAdmin** page in the Workflow Commons.
@@ -260,3 +264,7 @@ You can do one of the following:
 * The workflow can be restarted, for example, by using the **DefaultWorkflowAdmin** page in the Workflow Commons.
 * The Administrator can use **Mark-as-Resolved** to fix this issue (the currently running activity within the removed sub-process will be aborted).
 * The app developer can revert the change (which adds the event sub-process back) and deploy it.
+
+### Workaround for Non-resolvable and Partially Resolvable Conflicts
+
+If the goal is to update an existing workflow document so that running workflow instances are unaffected while new workflow instances execute the new workflow document version, the best workaround is to duplicate the workflow document. To do so, right-click the workflow document and select **Duplicate**. Then make the desired edits in the duplicate. Finally, point the **Call workflow** activity to the new (duplicated) workflow document so that new instances use the updated version.