Document Notification Workflow Element

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

@@ -8,21 +8,28 @@ weight: 20
 
 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. 
 
-There are two main types of boundary events:
+Boundary events have two key characteristics: a **type** that determines what triggers the event, and an **interrupting behavior** that determines what happens to the parent activity when the event is triggered.
 
-* **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.
+### Boundary Event Types
 
-* **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.
+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:
 
-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.
+* [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.
 
-Below is an example of what a non-interrupting timer boundary event looks like:
+### Interrupting Behavior
 
-{{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png" alt="Adding boundary events through drag and drop" width="200" >}}
+Each boundary event has an interrupting behavior that can be set to either interrupting or non-interrupting:
 
-Studio Pro now supports the following boundary event:
+* **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 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.
 
-* [Timer](/refguide/timer/)
+* **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 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 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 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" width="200" >}}
 
 ## Getting started
 
@@ -41,44 +48,40 @@ 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:
+1. 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" >}}
 
-* Right-click one of the above-listed activities to open its context menu, and click **Add boundary event**:
+2. 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/context-menu.png" alt="Adding boundary events through context menu" width="200" >}}
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png" alt="Adding boundary events through edit dialog" width="450" >}}
 
-* 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 **Select Event** dialog that opens, 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" width="450" >}}
 
-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 [Timer – Boundary Properties](/refguide/timer/#boundary-properties) or [Notification – Boundary Properties](/refguide/notification/#boundary-properties).
 
 #### 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">}}
 
 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 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.
 
 ### Rearranging Boundary Events
 
@@ -92,11 +95,11 @@ You can rearrange boundary events in the following ways:
 
     {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png" width="400px" 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 +137,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/workflow-elements/_index.md

@@ -55,9 +55,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}
 

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

@@ -0,0 +1,71 @@
+---
+title: "Notification"
+url: /refguide/notification/
+weight: 95
+#If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details.
+---
+
+## Introduction
+
+**Notification** allows you to suspend a workflow path until the workflow is notified.
+
+It can be used in the following two ways:
+
+* **Notification** can be used as a standalone event on a workflow path. It suspends the workflow path until the workflow receives a notification. Use it as a standalone event when you want the path to be blocked until the notification is received. For example, when a workflow needs to wait for an external system to confirm that a payment has been processed before continuing.
+
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/standalone-notification-event.png" alt="Standalone Notification event" width="250" >}}
+
+* **Notification** can also be attached to another workflow activity as a [Boundary Event](/refguide/workflow-boundary-events/). Use it as a boundary event when you want to either run a parallel path alongside the parent activity (non-interrupting) or redirect path execution by aborting the parent activity (interrupting).
+
+    {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/notification-boundary-event.png" alt="Notification boundary event" width="300" >}}
+
+{{% alert color="info" %}}
+The **Notification** element is an event and is represented as a circle in the workflow editor. This distinguishes it from the [Wait for Notification](/refguide/wait-for-notification/) activity, which is represented as a rounded square. Additionally, unlike **Wait for Notification**, it is not possible to attach boundary events to the **Notification** event.
+{{% /alert %}}
+
+{{% alert color="info" %}}
+If you have this element in one of the parallel split paths, then only the path which has this element will suspend and all the other paths will continue with their own activities.
+
+However, the whole parallel split will still suspend on the merge of the split until the notification is received.
+{{% /alert %}}
+
+## Properties
+
+**Notification** properties consist of the following sections:
+
+* [General](#general)
+* [Boundary properties](#boundary-properties)
+* [Common](#common)
+
+### General Section {#general}
+
+The **Caption** describes what happens in this element. It is displayed under the workflow element to make the **Notification** easier to read and understand without the need to add annotations.
+
+### Boundary Properties Section {#boundary-properties}
+
+{{% alert color="info" %}}
+This section is only applicable when **Notification** is used as a notification boundary event.
+{{% /alert %}}
+
+The **Interrupting** property sets the notification boundary event to be either interrupting or non-interrupting.
+
+By default, it is set to **No**, which means that the notification boundary event is non-interrupting. When it is set to **Yes**, the notification boundary event is interrupting. For more information, see [Boundary Events](/refguide/workflow-boundary-events/).
+
+### Common Section {#common}
+
+{{% alert color="info" %}}
+This section is only applicable when **Notification** is used as a standalone event on a workflow path.
+{{% /alert %}}
+
+**Name** is the internal name of the **Notification**. When referring to the element in an application, you will use this name. It must be unique within the workflow, but you can have two **Notification** events with the same name in different workflows.
+
+## Sending Notification
+
+To trigger the **Notification** event and resume the workflow path, use the [Notify Workflow](/refguide/notify-workflow/) microflow action.
+
+## Read More
+
+* [Workflows](/refguide/workflows/)
+* [Wait for Notification](/refguide/wait-for-notification/)
+* [Notify Workflow](/refguide/notify-workflow/)
+* [Workflow Versioning and Conflict Mitigation](/refguide/workflow-versioning/)