Merge pull request #11211 from DmytroKost/wor/notification-element

Document Notification Workflow Element

Author: Yiyun333

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

@@ -6,23 +6,33 @@ weight: 20
 
 ## Introduction
 
-Based on Business Process Model and Notation (BPMN) 2.0, boundary events are a type of event that is attached to the boundary of an activity (such as a task or a sub-process) to handle exceptional situations or are triggered by certain behaviors. 
+Boundary events are a type of event that is attached to the boundary of an activity (such as a task or a sub-process) to handle exceptional situations or are triggered by certain behaviors. 
 
-There are two main types of boundary events:
+Boundary events have the following two key characteristics: 
 
-* **Non-interrupting boundary events**: These events do not interrupt the ongoing activity. When triggered, they allow the activity to continue while simultaneously starting a new path from the boundary event. Use non-interrupting boundary events when the parent activity should remain active, but you would like to do something in parallel. For example, after 2 days, a reminder should be sent to the assigned user. As per BPMN 2.0 specification, non-interrupting boundary events are visualized as two dashed circles with an icon in the center.
+* A **type** that determines what triggers the event
+* An **interrupting behavior** that determines what happens to the parent activity when the event is triggered
 
-* **Interrupting boundary events**: When these events are triggered, they interrupt the activity they are attached to, meaning that this activity will be aborted. The process flow is redirected to the boundary event's outgoing sequence path. Use interrupting boundary event in situations where further execution of the activity (and other following activities) is not required and an alternative path should be taken. For example, use an interrupting boundary event to start an escalation or a fast-track path when an activity is not completed 2 days after the due date. Or when the assigned user does not make a decision within 5 days, you want to abort the user task and continue the process with a pre-set decision. As per BPMN 2.0 specification, interrupting boundary events are visualized as two solid circles.
+### Boundary Event Types
 
-Boundary Events are always displayed by 2 circles (either solid or dashed) and are linked by a dotted line to the parent activity. The icon inside the event indicates the type of event. For example, a clock indicates that it is a timer boundary event.
+The boundary event type determines what triggers the event. The icon inside the event indicates its type. Studio Pro supports the following boundary event types:
 
-Below is an example of what a non-interrupting timer boundary event looks like:
+* [Timer](/refguide/timer/) – triggered after a configured duration or at a specific date and time.
+* [Notification](/refguide/notification/) – triggered when the workflow receives a notification.
 
-{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png" alt="Adding boundary events through drag and drop" width="200" >}}
+### Interrupting Behavior
 
-Studio Pro now supports the following boundary event:
+Each boundary event has an interrupting behavior that can be set to either interrupting or non-interrupting:
 
-* [Timer](/refguide/timer/)
+* **Non-interrupting**: These events do not interrupt the ongoing activity. When triggered, they allow the activity to continue while simultaneously starting a new path from the boundary event. Use non-interrupting boundary events when the parent activity should remain active, but you would like to do something in parallel. For example, after two days, a reminder should be sent to the assigned user. Non-interrupting boundary events are visualized as two dashed circles with an icon in the center.
+
+* **Interrupting**: When these events are triggered, they interrupt the activity they are attached to, meaning that this activity will be aborted. The process flow is redirected to the boundary event's outgoing sequence path. Use interrupting boundary events in situations where further execution of the activity (and other following activities) is not required and an alternative path should be taken. For example, use an interrupting boundary event to start an escalation or a fast-track path when an activity is not completed two days after the due date. Or when the assigned user does not make a decision within five days, you want to abort the user task and continue the process with a pre-set decision. Interrupting boundary events are visualized as two solid circles.
+
+Boundary events are always displayed by two circles (either solid or dashed) and are linked by a dotted line to the parent activity. The icon inside the event indicates the boundary event type. For example, a clock indicates that it is a timer boundary event, and an envelope indicates that it is a notification boundary event.
+
+Below is an example of what a non-interrupting timer boundary event looks like:
+
+{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png" alt="Adding boundary events through drag and drop" max-width=80% >}}
 
 ## Getting started
 
@@ -41,62 +51,62 @@ When a boundary event is added to an activity, this activity is also referred to
 
 ### Adding Boundary Events
 
-{{% alert color="info" %}}
-Currently, a timer boundary event is added by default since it is the only option.
-{{% /alert %}}
-
 To add a boundary event to the [above-listed activities](#supported-activities), choose one of the following ways:
 
 * Select an event from the **Events** section in the workflow **Toolbox** and drag it onto one of the activities listed above:
 
-    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png" alt="Adding boundary events through drag and drop" width="200" >}}
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png" alt="Adding boundary events through drag and drop" max-width=80%  >}}
+
+* Double-click one of the above-listed activities to open its properties dialog box, go to the **Events** tab, and in the **Boundary events** section, click **Add**:
+
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png" alt="Adding boundary events through edit dialog" max-width=80%  >}}
 
 * Right-click one of the above-listed activities to open its context menu, and click **Add boundary event**:
 
-    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png" alt="Adding boundary events through context menu" width="200" >}}
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png" alt="Adding boundary events through context menu" max-width=80%  >}}
 
-* Double-click one of the above-listed activities to open its properties dialog box, go to the **Events** tab, and in the > **Boundary events** section, click **Add timer event** to add a timer boundary event:
+In the latter two cases, the **Select Event** dialog appears where you choose the type of boundary event you want to add:
 
-    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png" alt="Adding boundary events through edit dialog" width="450" >}}
+{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/select-event.png" alt="Select Event dialog" max-width=80%  >}}
 
-To configure the properties of a boundary event, double-click the event to open its properties dialog box. For more information on how to configure the properties of a timer boundary event, see [Boundary Properties](/refguide/timer/#boundary-properties).
+To configure the properties of a boundary event, double-click the event to open its properties dialog box. For more information on how to configure boundary event properties, see the [Boundary Properties](/refguide/timer/#boundary-properties) section in *Timer* or the [Boundary Properties](/refguide/notification/#boundary-properties) in *Notification*.
 
 #### Adding a Boundary Event to an Ongoing Activity
 
 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.
 
-#### Implications of Changing the Boundary Event Type {#event-type-change}
+#### Implications of Changing the Interrupting Behavior {#event-type-change}
 
-For an existing boundary event, when you change its type 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:
+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:
 
-{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/security-dialog.png" alt="Security Dialog when changing type" width="450">}}
+{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/security-dialog.png" alt="Security Dialog when changing type" max-width=80% >}}
 
 After you confirm the change:
 
-* The boundary event is re-created with the specified type. The new boundary event will be scheduled after the workflow is redeployed and becomes in progress.
+* The boundary event is re-created with the specified interrupting behavior. The new boundary event will be scheduled after the workflow is redeployed and becomes in progress.
 * The workflow will become incompatible if the changed boundary event has already been executed. The workflow becomes incompatible for the following reasons:
     * If the changed boundary event was non-interrupting, you will get the [Non-interrupting Boundary Event Path Removed](/refguide/workflow-versioning/#non-interrupting-boundary-event-path-removed) conflict.
     * If the changed boundary event was interrupting, you will get the [Current Activity Removed](/refguide/workflow-versioning/#current-activity-removed) conflict.
 
-Boundary events are re-created upon type switch because in-place conversion can result in states that contradict BPMN 2.0 concepts. According to BPMN, 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 BPMN rule that a non-interrupting boundary event must not abort its parent.
+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.
 
 ### Rearranging Boundary Events
 
 You can rearrange boundary events in the following ways:
 
 * Right-click a boundary event to open its context menu and click **Move boundary event left** or **Move boundary event right**, or use the <kbd>Ctrl</kbd>/<kbd>Command</kbd> + Left arrow or <kbd>Ctrl</kbd>/<kbd>Command</kbd> + Right arrow shortcut keys.
 
-    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-editor.png" width="400px" alt="Timer Event arrange in editor" >}}
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-editor.png" max-width=80%  alt="Timer Event arrange in editor" >}}
 
-* Double-click the parent activity to open its properties dialog box and click **Move up** or **Move down**  to change the order of the boundary events' paths.
+* Double-click the parent activity to open its properties dialog box and click **Move up** or **Move down** to change the order of the boundary events' paths.
 
-    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png" width="400px" alt="Arrange non-interrupting boundary event in dialog" >}}
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png" max-width=80%  alt="Arrange non-interrupting boundary event in dialog" >}}
 
-    {{% alert color="info" %}}This does not change the order execution of the paths, as this is dependent on the expiration of the timer.{{% /alert %}}
+    {{% alert color="info" %}}This does not change the order of execution of the paths, as this is dependent on when the boundary event is triggered.{{% /alert %}}
 
 ## Execution
 
-Boundary events are initiated when their parent activity is initiated. For example, for a timer with a fixed duration, it will start its countdown when the parent activity is initiated. When the parent activity is completed before any of the boundary events are triggered, none of the activities in the boundary event path will be executed and all timers will be cancelled.
+Boundary events are initiated when their parent activity is initiated. For example, for a timer boundary event with a fixed duration, it will start its countdown when the parent activity is initiated. When the parent activity is completed before any of the boundary events are triggered, none of the activities in the boundary event path will be executed and all pending boundary events will be cancelled.
 
 ### Non-Interrupting Boundary Events
 
@@ -134,6 +144,8 @@ The list of variables is described below:
 ## Read more
 
 * [Workflows](/refguide/workflows/)
+* [Timer](/refguide/timer/)
+* [Notification](/refguide/notification/)
 * [Add Date Function Calls](/refguide/add-date-function-calls/)
 * [Parse and Format Date Function Calls](/refguide/parse-and-format-date-function-calls/)
 * [Workflow Versioning and Conflict Mitigation](/refguide/workflow-versioning/)

content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md

@@ -67,7 +67,7 @@ After you confirm the change:
 * The sub-process is re-created with a start event of the specified type, along with all the event sub-process activities. The new start event can be triggered after the workflow is redeployed and is in progress.
 * The workflow becomes incompatible if the changed event sub-process is already being executed in one of the ongoing workflow instances.
 
-The event sub-process is re-created upon type switch because in-place conversion can result in states that contradict BPMN 2.0 concepts. According to BPMN, an interrupting event sub-process cancels the parent process scope and all other active sub-processes when triggered, while a non-interrupting one runs in parallel without affecting them. These are mutually exclusive execution models: an event sub-process instance belongs to exactly one of them from the moment it starts. Changing the type in place for an already-active instance would leave it in a state that is neither valid interrupting nor valid non-interrupting behavior, violating the fundamental BPMN distinction between the two.
+The event sub-process is re-created upon type switch because in-place conversion can result in invalid states. An interrupting event sub-process cancels the parent process scope and all other active sub-processes when triggered, while a non-interrupting one runs in parallel without affecting them. These are mutually exclusive execution models: an event sub-process instance belongs to exactly one of them from the moment it starts. Changing the type in place for an already-active instance would leave it in a state that is neither valid interrupting nor valid non-interrupting behavior.
 
 #### Concurrency Limitation
 

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

@@ -56,9 +56,10 @@ The elements of this category are described in the table below:
 
 The elements of this category are described in the table below:
 
-| Graphic                                                     | Element                           | Description                                                  |
-| ----------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------ |
-{{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer.png" width="50px" alt="timer activity" class="no-border" >}} | [Timer](/refguide/timer/)             | Allows you to configure a certain duration or a specific date and time in a workflow. It can be used as a standalone activity on a workflow path or as a [Boundary Event](/refguide/workflow-boundary-events/) attached to another workflow activity.|
+| Graphic                                                     | Element                           | Description                                                                                                                                                                                                                                        |
+| ----------------------------------------------------------- | --------------------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer.png" width="50px" alt="timer activity" class="no-border" >}} | [Timer](/refguide/timer/)             | Allows you to configure a certain duration or a specific date and time in a workflow. It can be used as a standalone event on a workflow path or as a [Boundary Event](/refguide/workflow-boundary-events/) attached to another workflow activity. |
+| {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification.png" width="50px" alt="notification event" class="no-border" >}} | [Notification](/refguide/notification/)             | Allows you to suspend a workflow path until the workflow is notified. It can be used as a standalone event on a workflow path or as a [Boundary Event](/refguide/workflow-boundary-events/) attached to another workflow activity.                 |
 
 ## System Actions {#system}