Timer Event Sub-Process Recurrence - #11779
Conversation
|
|
||
| {{% alert color="info" %}} | ||
| This section is only applicable when **Notification** is used as a notification boundary event. | ||
| This section is only applicable when **Notification** is used as a notification boundary event or as the start event of a notification event sub-process. |
There was a problem hiding this comment.
We can remove the notification specificity here. We also don't do it for the boundary event. So it would become:
This section is only applicable when Notification is used as a notification boundary event or as the start event of an event sub-process.
| 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} | ||
| ### Interrupting Behavior Section {#boundary-properties} |
There was a problem hiding this comment.
The UI will be updated, and this will be the section title for both the Start and Boundary events. -> WOR-3080
|
|
||
| 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/). | ||
| {{% alert color="info" %}} | ||
| Changing the interrupting behavior of an existing notification boundary event or notification event sub-process re-creates it, and it can make ongoing workflow instances incompatible. For more information, see *Implications of Changing the Interrupting Behavior* in [Boundary Events](/refguide/workflow-boundary-events/#event-type-change) or [Event Sub-Processes](/refguide/workflow-event-sub-processes/#event-type-change). |
There was a problem hiding this comment.
Should we shorten these kinds of text from
notification boundary event or notification event sub-process to just 'event'
Result:
Changing the interrupting behavior of an existing event re-creates it, and it can make ongoing workflow instances incompatible. For more information, see *Implications of Changing the Interrupting Behavior
| The **Caption** describes what happens in this element. It is displayed under the workflow element to make the **Timer** easier to read and understand without the need to add annotations. | ||
|
|
||
| ### Boundary Properties Section {#boundary-properties} | ||
| ### Interrupting Behavior {#boundary-properties} |
There was a problem hiding this comment.
For notification, this says Interrupting Behavior Section. Lets also do that for this because there is a story to rename Boundary properties to Interrupting behavior - WOR-3080
|
|
||
| * **Notification start event** – The sub-process is triggered by a [Notify workflow](/refguide/notify-workflow/) microflow activity. | ||
| * **Timer start event** – The sub-process is triggered automatically when the configured duration elapses or the configured date and time is reached. The timer configuration follows the same rules as the standalone [Timer](/refguide/timer/) activity. For more information, refer to the [Timer](/refguide/timer/#timer) section in *Timer*. | ||
| * **Timer start event** – The sub-process is triggered automatically when the configured duration elapses or the configured date and time is reached. The timer configuration follows the same rules as the standalone [Timer](/refguide/timer/) activity. For more information, refer to the [Timer](/refguide/timer/#timer) section in *Timer*. A non-interrupting timer start event can also be configured to fire repeatedly; see the [Recurrence](/refguide/timer/#recurrence) section in *Timer*. |
There was a problem hiding this comment.
The timer configuration follows the same rules as the standalone [Timer](/refguide/timer/) activity.
The standalone timer has no recurrence, correct? We could also remove this sentense and just point to the timer documentaiton
3 participants
For 11.15