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 6b2401e3ea4..085ecaf1143 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 @@ -6,23 +6,30 @@ 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 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. 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. 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,44 @@ 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/edit-dialog.png" alt="Adding boundary events through edit dialog" width="450" >}} - {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png" alt="Adding boundary events through context menu" width="200" >}} +3. Right-click one of the above-listed activities to open its context menu, and click **Add boundary event**: -* 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: + {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png" alt="Adding boundary events through context menu" width="450" >}} - {{< figure src="/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png" alt="Adding boundary events through edit dialog" width="450" >}} +In both cases (options 2 and 3), the **Select Event** dialog appears where you choose the type of boundary event you want to add: -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). +{{< 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 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 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 @@ -92,11 +99,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 +141,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/) diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md b/content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md index 6373273a358..df19c052e20 100644 --- a/content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md +++ b/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 diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/_index.md b/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/_index.md index a17d872e352..945539d0957 100644 --- a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/_index.md +++ b/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} diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/notification.md b/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/notification.md new file mode 100644 index 00000000000..f42ad6e6345 --- /dev/null +++ b/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/) diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/timer.md b/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/timer.md index 44d85c82905..0e33e0e0ee3 100644 --- a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/timer.md +++ b/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/timer.md @@ -13,11 +13,11 @@ aliases: It can be used in the following two ways: -* **Timer** can be used as a standalone activity on a workflow path. It suspends the workflow path for a configurable duration or until a set date and time. For example, when a new salary legislation is about to take effect, a timer can be set until the date of effect to actually adjust the values in the system. +* **Timer** can be used as a standalone event on a workflow path. It suspends the workflow path for a configurable duration or until a set date and time. Use it as a standalone event when you want the path to be blocked until the timer fires. For example, when a new salary legislation is about to take effect, a timer can be set until the date of effect to actually adjust the values in the system. {{< figure src="/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer/standalone-timer-activity.png" alt="Standalone Timer activity" width="250" >}} -* **Timer** can also be attached to another workflow activity as a [Boundary Event](/refguide/workflow-boundary-events/): +* **Timer** 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/timer/timer-boundary-event.png" alt="Timer boundary event" width="300" >}} @@ -57,7 +57,7 @@ The **Timer** properties are described in the table below: | Expression | You can set a certain date and time for the timer by writing an expression via the **Continue at** setting.

For example, you can write `addDays([%CurrentDateTime%], 1)` to set tomorrow as the due date and time. To set a static date and time, you can use the expression `parseDateTimeUTC('2023-12-10T17:12:00.000', 'yyyy-MM-dd''T''HH:mm:ss.SSS')`.

You can also create a more complex timer. For example, you can set a timer based on a Boolean value (in this example, `isVIPUser`) from the provided workflow context entity: `if $WorkflowContext/isVIPUser then addDays([%CurrentDateTime%], 2) else addWeeks([%CurrentDateTime%], 2])`.

For more information on available expressions in Mendix, see [Expressions](/refguide/expressions/). | {{% alert color="info" %}} -When the expression evaluates to `empty` or `null`, no timer is scheduled. If the timer is a standalone activity, execution continues with the next activity. If it is a timer boundary event, the boundary event is skipped. +When the expression evaluates to `empty` or `null`, no timer is scheduled. If the timer is a standalone event, execution continues with the next activity. If it is a timer boundary event, the boundary event is skipped. {{% /alert %}} ### Recurrence Section {#recurrence} @@ -80,7 +80,7 @@ When recurrence is set, the non-interrupting boundary event is first executed af ### Common Section {#common} {{% alert color="info" %}} -This section is only applicable when **Timer** is used as a standalone activity on a workflow path. +This section is only applicable when **Timer** is used as a standalone event on a workflow path. {{% /alert %}} **Name** is the internal name of the **Timer**. When referring to the activity in an application, you will use this name. It must be unique within the workflow, but you can have two **Timer** activities with the same name in different workflows. @@ -106,7 +106,7 @@ The following cases do not trigger a continuation of the workflow path when time ### Workflow Incompatibility {{% alert color="info" %}} -This section is only applicable when **Timer** is used as a standalone activity on a workflow path. +This section is only applicable when **Timer** is used as a standalone event on a workflow path. {{% /alert %}} When a **Timer** activity is added to the workflow definition and the application is redeployed, a validation on already running workflow instances is performed. When the **Timer** activity has been added before the currently in-progress activity, the workflow becomes incompatible. The conflict/incompatibility validation is analogous to other activities added before an in-progress activity. For more information, see [Workflow Versioning and Conflict Mitigation](/refguide/workflow-versioning/). diff --git a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/wait-for-notification.md b/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/wait-for-notification.md index 6d091db78d2..65703caa1a6 100644 --- a/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/wait-for-notification.md +++ b/content/en/docs/refguide/modeling/application-logic/workflows/workflow-elements/wait-for-notification.md @@ -37,6 +37,11 @@ Boundary events can be attached to this element and are triggered by certain eve **Name** is the internal name of the wait for notification activity. When referring to the wait for notification in the app, you will use this name. It must be unique within the workflow, but you can have two wait for notification activities with the same name in different workflows. +## Sending Notification + +To trigger the **Wait for notification** activity and resume the workflow path, use the [Notify Workflow](/refguide/notify-workflow/) microflow action. + ## Read More * [Workflows](/refguide/workflows/) +* [Notify Workflow](/refguide/notify-workflow/) diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png index 91e05d8ab2e..290f71873f4 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-dialog.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-editor.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-editor.png index f0708aa2831..43263043f05 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-editor.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/arrange-in-editor.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png index c521cf44a6e..0be677af641 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/context-menu.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png index b2d3b944cf7..3b0a517a61c 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/drag-drop.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png index 9056558d513..60a82aee82f 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/edit-dialog.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/interrupting-property.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/interrupting-property.png index d27eb50dd50..1818133918f 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/interrupting-property.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/interrupting-property.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/security-dialog.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/security-dialog.png index c646b43bdf4..818e31386fa 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/security-dialog.png and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/security-dialog.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/select-event.png b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/select-event.png new file mode 100644 index 00000000000..b6be398e41c Binary files /dev/null and b/static/attachments/refguide/modeling/application-logic/workflows/boundary-events/select-event.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification.png b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification.png new file mode 100644 index 00000000000..a3faf3633ee Binary files /dev/null and b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/notification-boundary-event.png b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/notification-boundary-event.png new file mode 100644 index 00000000000..192083619ad Binary files /dev/null and b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/notification-boundary-event.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/standalone-notification-event.png b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/standalone-notification-event.png new file mode 100644 index 00000000000..a619a91306f Binary files /dev/null and b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/notification/standalone-notification-event.png differ diff --git a/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer.png b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer.png index 1a8c613e49f..3efdbc2a34d 100644 Binary files a/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer.png and b/static/attachments/refguide/modeling/application-logic/workflows/workflow-elements/timer.png differ