@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.being-able-to-react-all-the-time.md

@@ -0,0 +1,42 @@
+# Modeling beyond the happy path — Being able to react all the time
+
+A bit similar to boundary events, with BPMN event subprocesses we can deal with problems arising while we are actively occupied to carry out work. The main advantage when being compared with boundary events is that some issues can _occur almost anywhere_ on our way through the happy path.
+
+### Dealing with issues occurring almost anywhere
+
+Some issues can occur almost anywhere on the way through our process. The event subprocess allows us to fork off a _problem path_ modeled separately from our main process to deal with such issues:
+
+Diagram (BPMN):
+  start "Order received" → subprocess → event-based gateway
+    — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+    — intermediate catch event "Ordered good not deliverable" → exclusive gateway → "Inform customer" → end "Order not deliverable"
+    — intermediate catch event "Answer overdue" → (back to exclusive gateway)
+
+**(1)**
+
+The _non-interrupting start message event_ of the event subprocess allows us to express that wherever we currently are on our way through order confirmation, it can happen that the customer requests information about the status of that process.
+
+**(2)**
+
+We should then provide the requested information without interferring with the order confirmation process itself.
+
+### Dealing with canceling the process
+
+Another typical use case for event-based subprocesses is a cancellation requested by the customer:
+
+Diagram (BPMN):
+  start "Order received" → subprocess → event-based gateway
+    — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+    — intermediate catch event "Ordered good not deliverable" → exclusive gateway → "Inform customer" → end "Order not deliverable"
+    — intermediate catch event "Answer overdue" → (back to exclusive gateway)
+
+**(1)**
+
+The _interrupting start message event_ of the event subprocess allows us to express that wherever we currently are on our way through order confirmation, it can happen that the customer requests cancellation.
+
+**(2)**
+
+We should then interrupt the main process (which is already expressed by the nature of the start event) and inform an involved dealer.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.boundary-events-as-alternative-for-event-based-gateways-modeling-a-multi-phase-escalation-path.md

@@ -0,0 +1,41 @@
+# Modeling beyond the happy path — Boundary events as alternative for event based gateways — Modeling a multi phase escalation path
+
+Boundary events are particularly useful when you consider that you might want to remind your dealer that the answer is overdue and give them another chance for transmitting the delivery date before you give up waiting. First, consider how this could be achieved by using event-based gateways:
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → event-based gateway
+        — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+        — intermediate catch event "Ordered good not deliverable" → exclusive gateway → "Inform customer" → end "Order not deliverable"
+        — intermediate catch event "Answer overdue" → exclusive gateway "Dealer already reminded?"
+          — [Yes: =reminded] (back to exclusive gateway)
+          — [No: =not(reminded)] "Remind dealer" → (back to event-based gateway)
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+After having realized that the dealer's answer is late, we decide whether we want to remind the dealer and continue to wait - or not. We modeled here that we want to remind the dealer just once.
+
+**(2)**
+
+However, note that while we are reminding the dealer, we are strictly speaking not in a state "ready-to-receive" the dealer's answer! According to BPMN execution semantics, the dealer's message might get lost until we are back at the event-based gateway. While you might want to choose to ignore that when modeling for communication purposes only, you will need to get it right for executable models.
+
+To get the BPMN execution semantics above fully right, we would now need to attach the two possible answers of the dealer ("Delivery data fixed", "Ordered good not available") as boundary events to the task "Remind dealer", too! Quite a modeling construct, just to properly wait for the dealer's response, right? Therefore, consider the following alternative to this modeling issue using boundary events only:
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → "Receive delivery date" → "Mail order confirmation" → end "Order confirmed"
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+Modeling a _non-interrupting boundary timer event_ directly at a task which waits for the response has the advantage that we never leave the "ready-to-receive" state and therefore avoid troubles with the strict interpretation of BPMN execution semantics.
+
+The second alternative is _very compact_ and avoids issues with _not being ready-to-receive_, but typically needs a _deeper understanding_ of BPMN symbols and their consequences for the token flow. Therefore, we sometimes also prefer event-based gateways for showing human flows, and ignore sophisticated token flow issues as discussed here.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.boundary-events-as-alternative-for-event-based-gateways-using-receive-tasks-with-boundary-events.md

@@ -0,0 +1,25 @@
+# Modeling beyond the happy path — Boundary events as alternative for event based gateways — Using receive tasks with boundary events
+
+The examples above leverage the _event based gateway_. BPMN also allows to model _receive tasks_ that wait for responses. This has the advantage that you now can leverage boundary events to deal with _missing results_ or other _events occuring while you are waiting_ for the response. This is an _alternative_ to the event-based gateways shown in the above models.
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → "Receive delivery date" → "Mail order confirmation" → end "Order confirmed"
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+Instead of modeling an event for receiving a delivery date, we model a _task_ here.
+
+**(2)**
+
+The fact that we do not receive such an answer at all can now be modeled as an _interrupting boundary timer event_. We inform the customer about the status, but as the timer is interrupting, do not wait any longer for the delivery date.
+
+**(3)**
+
+It might turn out that the ordered good is not deliverable. This can be modeled as _boundary message event_. Upon that message we cancel any further waiting but inform the customer about the status instead.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.forking-off-at-a-particular-point-dealing-with-events.md

@@ -0,0 +1,23 @@
+# Modeling beyond the happy path — Forking off at a particular point — Dealing with events
+
+By using event-based gateways, we _passively wait_ for _future events_ deciding about which path our process will have to move along. For example, we can therefore use use it to fork off a "problem path" dealing with an undesired event _outside of our own control_:
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → event-based gateway
+        — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+        — intermediate catch event "Ordered good not deliverable" → "Inform customer" → end "Order not deliverable"
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+After having requested a delivery date (e.g. from wholesale), we use an _event-based gateway_ to passively wait for what happens next. We can not know "now and here", because it's outside of our own control.
+
+**(2)**
+
+The _intermediate message event_ allows us to deal with the undesired event that the ordered good is not deliverable.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.forking-off-at-a-particular-point-dealing-with-missing-results-via-timeouts.md

@@ -0,0 +1,20 @@
+# Modeling beyond the happy path — Forking off at a particular point — Dealing with missing results via timeouts
+
+By using event-based gateways, we can also deal with the situation that _nothing relevant_ for our process _happens_. We do this by defining a time period, after which we decide that we do not want to wait any longer:
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → event-based gateway
+        — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+        — intermediate catch event "Ordered good not deliverable" → exclusive gateway → "Inform customer" → end "Order not deliverable"
+        — intermediate catch event "Answer overdue" → (back to exclusive gateway)
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+The _intermediate timer event_ allows us to deal with the situation that nothing relevant for our process happened for a defined time period. In case we do not get an answer from wholesale, we inform the customer that the order is not deliverable at the moment.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.forking-off-at-a-particular-point-dealing-with-results.md

@@ -0,0 +1,25 @@
+# Modeling beyond the happy path — Forking off at a particular point — Dealing with results
+
+By using data-based gateways, we _actively decide_ "now and here" on the basis of our own _process data_ which path our process must move along. For example, we can therefore use an XOR gateway to fork off a "problem path," dealing with a problematic result of _our own activities_:
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+The _exclusive gateway_ deals with the potentially problematic result of incomplete order data. Note that we deal here with the procedural consequences of work which already took place in the preceding task, where we actually checked the order for completeness.
+
+**(2)**
+
+Again, the preceding task already dealt with the actual work of checking the customer's creditworthiness. The _result_ of the task is a "yes" or "no" (true or false). We can deal with data by means of a data-based gateway, which immediately redirects to the path our process must move along.
+
+**(3)**
+
+The _end event_ characterizes the undesired end result "order declined," which we now reach because of having modeled two problems. In the example, both of them lead to one and the same business outcome.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.forking-off-at-a-particular-point.md

@@ -0,0 +1,6 @@
+# Modeling beyond the happy path — Forking off at a particular point
+
+With BPMN gateways, we can deal with problems arising at a _particular point_ in our process.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.forking-off-during-one-or-several-activities.md

@@ -0,0 +1,46 @@
+# Modeling beyond the happy path — Forking off during (one or several) activities
+
+With BPMN boundary events, we can deal with problems arising _while we are actively occupied_ to carry out work in our process.
+
+### Dealing with errors
+
+A typical case is that it turns out to be _impossible to achieve the result_ of an activity while working on it. We can then choose to interrupt our work and fork off a "problem path" to deal with the issue:
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → exclusive gateway "Order complete?"
+    — [Yes: =complete] "Check customer's credit-worthiness" → exclusive gateway "Customer credit-worthy?"
+      — [Yes: =creditWorthy] "Request delivery date" → event-based gateway
+        — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+        — intermediate catch event "Ordered good not deliverable" → exclusive gateway → "Inform customer" → end "Order not deliverable"
+        — intermediate catch event "Answer overdue" → (back to exclusive gateway)
+      — [No: =not(creditWorthy)] exclusive gateway → end "Order declined"
+    — [No: =not(complete)] (back to exclusive gateway)
+
+**(1)**
+
+The _interrupting boundary error event_ allows us to deal with the fact that the order is not readable. As this prevents us from properly judging the completeness of the order, we cannot reach one of the expected results of our activity ("complete" or "not complete"), but instead deal with the problem by interrupting the activity and assuming the order to be declined.
+
+When modeling for business process automation, "dealing with errors" might be a highly technical concern. As a rule of thumb, we just want to show the _"business related" problems_ in a process model: those problems and errors which cause that our business process must move along a different path, because different work must be carried out as a reaction.
+
+An example for a typical technical concern would be that we currently cannot reach a system, which is why, for example, we want to re-attempt it another time later on. We do not show such purely technical problems in a business process diagram, not even in an executable one: (1) It would clutter the diagram, and (2) There are more suitable ways to deal with technical issues potentially occuring almost anywhere. Read our Best Practice about [dealing-with-problems-and-exceptions](https://docs.camunda.io/docs/next/components/best-practices/development/dealing-with-problems-and-exceptions) from a more technical point of view to learn more about the border between business related shown in a process diagram and purely technical concerns not shown in a process diagram.
+
+### Dealing with work on top of usual work
+
+Another typical use case for reacting to situations while we are actively occupied is that it sometimes turns out we need to do stuff _in addition to what we already do_:
+
+Diagram (BPMN):
+  start "Order received" → subprocess → event-based gateway
+    — intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+    — intermediate catch event "Ordered good not deliverable" → exclusive gateway → "Inform customer" → end "Order not deliverable"
+    — intermediate catch event "Answer overdue" → (back to exclusive gateway)
+
+**(1)**
+
+We encapsulate part of our process into a subprocess to enable us to express that while we are occupied with that part of the process, additional work might pop up.
+
+**(2)**
+
+The _non-interrupting boundary timer event_ allows us to speed up order preparation in case it takes longer than two days; for example, by informing a responsible manager.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-beyond-the-happy-path.md

@@ -0,0 +1,46 @@
+# Modeling beyond the happy path
+
+Model the happy path before collecting problems and exceptions, prioritizing them, and introducing them incrementally.
+
+First, model the happy path to the desired end result before collecting problems and exceptions, prioritizing them, and introducing them incrementally. Secondly, focus on one selected issue at a time, and choose the right techniques for modeling beyond the happy path.
+
+
+## The happy path and beyond
+
+The happy path is kind of the default scenario with a positive outcome, so no exceptions, errors, or deviations are experienced. Typically, you want to model the happy path first, and therefore you should define the desired _end result_, find a suitable _start event_, and collect the _activities_ and external _dependencies_ which _always_ need to be considered to reach the result.
+
+When we have that, the diagram shows the _happy path_ of a business process (or of the selectively chosen part of the end-to-end business process):
+
+Diagram (BPMN):
+  start "Order received" → "Check order completeness" → "Check customer's credit-worthiness" → "Request delivery date" → intermediate catch event "Delivery date fixed" → "Mail order confirmation" → end "Order confirmed"
+
+**(1)**
+
+_End Event_: It's often the easiest first step to agree upon the desired ("happy") end _result_ of a process.
+
+**(2)**
+
+_Start Event_: As a second step, one might agree upon a _trigger_ for the work leading to the end result.
+
+**(3)**
+
+_Activities_: After that, you can brainstorm and collect activities which _always_ need to be carried out to reach the result.
+
+**(4)**
+
+_Intermediate Events_: Optionally, you can brainstorm and collect _milestones_ (modeled as blank events) and important external _dependencies_ (e.g. modeled as message events).
+
+### Modeling beyond the happy path by error scenarios
+
+As soon as you have this happy path, start modeling beyond the happy path. Focus on _one_ particular, selected problem at a time.
+
+1. Try to _understand_ the worries for _the business_ in the light of the desired end result.
+
+1. Identify the _undesired end result_ the process will reach in case the problem cannot be mitigated. This informs you about the _end event_ you will eventually reach because of the problem.
+
+1. Identify the affected areas in the happy path. Can the problem occur at a _particular point_, _during_ (one or several) _activities_, or basically _all the time_? This will inform you about the most promising modeling technique for the problem: whether either _gateways_, _boundary events_, or _event-based subprocesses_ can serve you to fork off your "problem path".
+
+This best practice will guide you through practices that help you model beyond the happy path.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.asking-multiple-recipients-for-a-single-reply.md

@@ -0,0 +1,31 @@
+# Modeling with situation patterns — Asking multiple recipients for a single reply
+
+You offer something to or request something from multiple communication partners, but you actually just need the first reply.
+
+We sometimes also call that pattern **first come, first serve**.
+
+**Example:** A well-known personal transportation startup works with a system of relatively independent drivers. "Of course, when the customer requests a tour, speed is everything. Therefore, we need to limit a tour to those of our drivers who are close by. Of course, there might be several drivers within a similar distance. We then just offer the tour to all of them!"
+
+### Using a multi-instance task
+
+Diagram (BPMN):
+  start "Tour requested" → service task "Offer tour on platform" → service task "Determine drivers nearby pickup location" → send task "Message tour to nearby driver's" → intermediate catch event "Tour accepted" → end "Driver approaching"
+
+Diagram (BPMN):
+  start "Push offering received" → "Review offering" → exclusive gateway "Tour interesting?"
+    — [Yes: =interesting] "Accept tour" → end "Tour accepted"
+    — [No: =not(interesting)] end "Tour declined"
+  note: This attempt to accept the tour might be unsuccessful
+
+**(1)**
+
+After determining all drivers currently close enough to serve the customer, we push the information about the tour to all of those drivers.
+
+**(2)**
+
+We then wait for the reply of a single driver. Once we have it, the process won't wait any longer, proceeds to the end event, and informs the customer about the approaching driver.
+
+According to the process model, it is possible that another driver accepts the tour as well. However, as the process in the tour offering system is not waiting for the message anymore, it will get lost. As our process proceeded to the end event after the first reply, all subsequent messages are intentionally ignored in this process design.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.concurring-dependent-instances.md

@@ -0,0 +1,60 @@
+# Modeling with situation patterns — Concurring dependent instances
+
+You need to process a request, but need to make sure that you don't process several similar requests at the same time.
+
+**Example:** A bank worries about the increasing costs for creditworthiness background checks: "Such a request costs real money, and we often have packages of related business being processed at the same time. So we should at least make sure that if one credit check of a customer is already running, we do not want another credit check for the same customer to be performed at the same time."
+
+### Using message events
+
+Diagram (BPMN):
+  start "Credit-worthiness check requested" → service task "Determine active credit-worthiness check for customer" → exclusive gateway "Active instance available?"
+    — [No: =not(instanceAvailable)] intermediate throw event "Credit-worthiness check activated" → call activity "Determination of credit-worthiness" → service task "Determine waiting instances" → send task "Inform waiting instances" → exclusive gateway → end "Credit-worthiness checked"
+    — [Yes: =instanceAvailable] intermediate catch event "Credit-worthiness determined" → (back to exclusive gateway)
+
+**(1)**
+
+Once an instance passes this event and moves on to the subsequent actual determination of the creditworthiness...
+
+**(2)**
+
+...other instances will determine that there already exists an active instance and wait to be informed by this instance.
+
+**(3)**
+
+When the active instance has determined the creditworthiness, it will move on to inform the waiting instances...
+
+**(4)**
+
+...which will receive a message with a creditworthiness payload and be finished themselves with the needed information.
+
+The model explicitly shows separate steps (_determine_ and _inform_ waiting instances) which you might want to implement more efficiently within one single step doing both semantic steps at once by means of a small piece of programming code.
+
+### Using a timer event
+
+While using timer events can be a feasible approach in case you want to avoid communication between instances, we do not recommend it. For example, one downside is that such solutions cause delays and overhead due to the perdiodical queries and the loop.
+
+Diagram (BPMN):
+  start "Credit-worthiness check requested" → service task "Determine active credit-worthiness check for customer" → exclusive gateway "Active instance available?"
+    — [No: =not(instanceAvailable)] intermediate throw event "Credit-worthiness check activated" → call activity "Determination of credit-worthiness" → exclusive gateway → end "Credit-worthiness checked"
+    — [Yes: =instanceAvailable] intermediate catch event "Credit-worthiness check deferred" → exclusive gateway → service task "Determine active credit-worthiness check for customer" → exclusive gateway "Active instance available?"
+      — [No: =not(instanceAvailable)] (back to exclusive gateway)
+      — [Yes: =instanceAvailable] (back to exclusive gateway)
+
+**(1)**
+
+Once an instance passes this event and moves on to the subsequent actual determination of the creditworthiness...
+
+**(2)**
+
+...all other instances will go into a wait state for some time, but check periodically, if the active instance is finished.
+
+**(3)**
+
+When the active instance has determined the creditworthiness and finishes...
+
+**(4)**
+
+...all other instances will also finish after some time.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.distinguishing-undesired-results-from-fatal-problems-option-1-using-gateways-to-check-for-undesired-results.md

@@ -0,0 +1,13 @@
+# Modeling with situation patterns — Distinguishing undesired results from fatal problems — Option 1: Using gateways to check for undesired results
+
+Diagram (BPMN):
+  start "Credit card application received" → service task "Evaluate credit-worthiness" → exclusive gateway "Applicant credit-worthy?"
+    — [No: =not(creditWorthy)] send task "Reject credit card application" → end "Credit card application rejected"
+    — [Yes: =creditWorthy] user task "Issue credit card" → end "Credit card application accepted"
+
+**(1)**
+
+Showing the check for the applicant's creditworthiness as a gateway also informs about the result of the preceding task: the applicant might be creditworthy - or not. Both outcomes are _valid results_ of the task, even though one of the outcomes here might be _undesired_ from a business perspective.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.distinguishing-undesired-results-from-fatal-problems-option-2-using-boundary-error-events-to-check-for-fatal-problems.md

@@ -0,0 +1,15 @@
+# Modeling with situation patterns — Distinguishing undesired results from fatal problems — Option 2: Using boundary error events to check for fatal problems
+
+Diagram (BPMN):
+  start "Credit card application received" → service task "Evaluate credit-worthiness" → exclusive gateway "Applicant credit-worthy?"
+    — [No: =not(creditWorthy)] exclusive gateway → send task "Reject credit card application" → end "Credit card application rejected"
+    — [Yes: =creditWorthy] user task "Issue credit card" → end "Credit card application accepted"
+
+**(1)**
+
+Not to know anything about the creditworthiness (because we cannot even retrieve information about the applicant) is not considered to be a valid result of the step, but a _fatal problem_ hindering us to achieve any valid result. We therefore model it as a boundary error event.
+
+The fact that both problems (an unknown applicant number or an applicant which turns out not to be credit-worthy) lead us at the moment to the same reaction in the process (we reject the credit card application) does not influence that we need to model it differently. The decision in favor of a gateway or an error boundary event solely depends on the exact definition of the result of a process step. Refer to the next section.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.distinguishing-undesired-results-from-fatal-problems-understanding-the-definition-of-the-result.md

@@ -0,0 +1,19 @@
+# Modeling with situation patterns — Distinguishing undesired results from fatal problems — Understanding the definition of the result
+
+What we want to consider to be a valid result for a process step depends on assumptions and definitions. We might have chosen to model the process above with slightly different execution semantics, while achieving the same business semantics:
+
+Diagram (BPMN):
+  start "Credit card application received" → service task "Evaluate credit-worthiness" → user task "Issue credit card" → end "Credit card application accepted"
+
+**(1)**
+
+The only valid result for the step "Ensure credit-worthiness" is knowing that the customer is in fact credit-worthy. Therefore, any other condition must be modeled with an error boundary event.
+
+To advance clarity by means of process models, it is absolutely crucial for modelers to have a clear mental definition of the _result_ a specific step produces, and as a consequence, to be able to distinguish _undesired results_ from _fatal problems_ hindering us to achieve any result for the step.
+
+While there is not necessarily a right way to decide what to consider as a valid result for your step, the business reader will typically have a mental preference to observe certain business issues, either more as undesired outcomes or more as fatal problems. However, for the executable pools, your discretion to decide about a step's result might also be limited when using, for example, service contracts which are already pre-defined.
+
+The same distinction applies to a step carried out by an [AI agent](https://docs.camunda.io/docs/next/reference/glossary#ai-agent). The response the agent returns when its loop ends is a valid result you check with a gateway, even when that response is a negative one. An error the agent itself raises, such as reaching its configured maximum number of model calls, is a fatal problem you catch with a boundary [error event](https://docs.camunda.io/docs/next/components/connectors/out-of-the-box-connectors/agentic-ai-aiagent-subprocess#error-handling).
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.distinguishing-undesired-results-from-fatal-problems.md

@@ -0,0 +1,8 @@
+# Modeling with situation patterns — Distinguishing undesired results from fatal problems
+
+You model a certain step in a process and wonder about undesired outcomes and other problems hindering you to achieve the result of the step.
+
+**Example:** What today is a problem for the business might become part of the happy path in a less successful future: "Before we can issue a credit card, we must ensure that a customer is credit-worthy. Unfortunately sometimes it might also turn out that we cannot even get any information about the customer. Then we typically also reject at the moment. Luckily, we do have enough business with safe customers anyway."
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.escalating-a-situation-step-by-step-option-1-using-event-based-gateways.md

@@ -0,0 +1,30 @@
+# Modeling with situation patterns — Escalating a situation step by step — Option 1: Using event-based gateways
+
+Diagram (BPMN):
+  start "Good needed" → user task "Order good" → event-based gateway
+    — intermediate catch event "Good delivered" → exclusive gateway → end "Good received"
+    — intermediate catch event "Reasonable time for reminder passed" → user task "Remind dealer" → event-based gateway
+      — intermediate catch event "Good delivered" → (back to exclusive gateway)
+      — intermediate catch event "Reasonable time for delivery ultimately passed" → user task "Cancel order" → end "Good not received"
+
+**(1)**
+
+After ordering the goods, the process passively waits for the success case by means of an event-based gateway: the goods should be delivered. However, in case this does not happen within a reasonable time, we make a first step of escalation: remind the dealer.
+
+**(2)**
+
+We still stay optimistic. Therefore, the process again passively waits for the success case by means of another event-based gateway: the goods should still be delivered. However, in case this does not happen again within a reasonable time, we make a second step of escalation: cancel the deal.
+
+**Evaluation:**
+
+- This solution explicitly shows how the two steps of this escalation are performed. Timers are modeled separately, followed by their corresponding escalation activities.
+
+- The usage of separate event-based gateways leads to _duplication_ (for example, of the receiving message events) and makes the model _larger_, even more so in case multiple steps of escalation need to be modeled.
+
+- During the time we need to remind the dealer, we are strictly speaking not in a position to receive the goods! According to the BPMN specification, a process can handle a message event only if it is ready to receive at exactly the moment it occurs. Fortunately, Camunda 8 introduced [message buffering](https://docs.camunda.io/docs/next/components/concepts/messages#message-buffering), allowing to execute this model properly without loosing messages. Using Camunda 7, the message might get lost until we are at the second event-based gateway.
+
+**Note**
+You might want to use that pattern when modeling _simple two phase escalations_. You should not execute it on Camunda 7.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.escalating-a-situation-step-by-step-option-2-using-gateways-forming-a-loop.md

@@ -0,0 +1,31 @@
+# Modeling with situation patterns — Escalating a situation step by step — Option 2: Using gateways forming a loop
+
+Diagram (BPMN):
+  start "Good needed" → user task "Order good" → exclusive gateway → event-based gateway
+    — intermediate catch event "Good delivered" → end "Good received"
+    — intermediate catch event "Reasonable time passed" → exclusive gateway "Dealer already reminded?"
+      — [No: =not(reminded)] user task "Remind dealer" → (back to exclusive gateway)
+      — [Yes: =reminded] user task "Cancel order" → end "Good not received"
+  note: Note that the timer label needs to be more generic here
+
+**(1)**
+
+After having ordered the goods, the process passively waits for the success case by means of an event-based gateway: the goods should be delivered. However, in case this does not happen within a reasonable time...
+
+**(2)**
+
+We choose by means of an exclusive gateway to make a _first step of escalation_: remind the dealer. We still stay optimistic. Therefore, the process returns to the event-based gateway and again passively waits for the success case: the goods should still be delivered. However, in case this does not happen again within a reasonable time, we choose a _second step of escalation_: cancel the deal.
+
+**Evaluation:**
+
+- This model is a more _compact_ and more _generic_ modeling solution to the situation. If it comes to multiple steps of escalation, you will need such an approach to avoid huge diagrams.
+
+- The solution is _less explicit_. We could not choose to label the timer with explicit durations, as a single timer is used for both durations. The solution is _less readable_ for a less experienced reading public. For a fast understanding of the two step escalation, this method of modeling is less suitable.
+
+- During the time we need to remind the dealer, we are strictly speaking not in a position to receive the goods! According to the BPMN specification, a process can handle a message event only if it is ready to receive at exactly the moment it occurs. Fortunately, Camunda 8 introduced [message buffering](https://docs.camunda.io/docs/next/components/concepts/messages#message-buffering), allowing to execute this model properly without loosing messages. Using Camunda 7, the message might get lost until we are at the second event-based gateway.
+
+**Note**
+You might want to use that pattern when modeling _escalations with multiple steps_. You should not execute it on Camunda 7.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.escalating-a-situation-step-by-step-option-3-using-boundary-events.md

@@ -0,0 +1,30 @@
+# Modeling with situation patterns — Escalating a situation step by step — Option 3: Using boundary events
+
+Diagram (BPMN):
+  start "Good needed" → user task "Order good" → receive task "Wait for delivery of good" → end "Good received"
+
+**(1)**
+
+After having ordered the goods, the process passively waits for the success case by means of a receive task: the goods should be delivered. However, in case this does not happen within a reasonable time...
+
+**(2)**
+
+a non-interrupting boundary timer event triggers a _first step of escalation_: remind the dealer. We still stay optimistic. Therefore, we did not interrupt the receive task, but continued to wait for the success case: the goods should still be delivered.
+
+**(3)**
+
+However, in case this does not happen within a reasonable time, we trigger a _second step of escalation_ by means of an interrupting boundary timer event: interrupt the waiting for delivery and cancel the deal.
+
+**Evaluation:**
+
+- This model is even more _compact_ and a very _generic_ modeling solution to the situation. If it comes to multiple steps of escalation, the non-interrupting boundary timer event could even trigger multiple times.
+
+- The model complies with BPMN execution semantics. Since we never leave the wait state, the process is always ready to receive incoming messages.
+
+- The solution is _less readable_ and _less intuitive_ for a less experienced reading public, because the way the interrupting and non-interrupting timers collaborate requires a profound understanding of boundary events and the consequences for token flow semantics. For communication purposes, this method of modeling is therefore typically less suitable.
+
+**Note**
+You might want to use that pattern when modeling _escalations with two steps_ as well as _escalations with multiple steps_ for _executable models._
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.escalating-a-situation-step-by-step.md

@@ -0,0 +1,12 @@
+# Modeling with situation patterns — Escalating a situation step by step
+
+You need something and hope that it happens. Such a hope for a result may materialize, but it does not have to! After some time, you will typically become impatient and try to do something to make it happen. But if it then still does not happen, there comes a point at which you will have to decide that you must accept a failure.
+
+We sometimes also call that very common pattern a **multi-step escalation**.
+
+**Example:** "A month ago, I ordered a pair of shoes with that new online shop! After two weeks of waiting: nothing. I contacted them to determine what's up. The clerk promised me that the shoes will leave the warehouse today! But again, nothing, so after another week I just canceled that order. Since then I did not hear a word."
+
+In this scenario, the shop clearly did not implement the escalation of the delay properly. They should have applied one of the following patterns in the order delivery process:
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.evaluating-decisions-in-processes.md

@@ -0,0 +1,43 @@
+# Modeling with situation patterns — Evaluating decisions in processes
+
+You need to come to a decision relevant for your next process steps. Your actual decision depends on a number of different factors and rules.
+
+We sometimes also call that pattern **business rules** in BPMN.
+
+**Example:** The freshly hired business analyst is always as busy as a bee: "Let's see... Category A customers always get their credit card applications approved, whereas Category D gets rejected by default. For B and C it's more complicated. Right, in between 2500 and 5000 Euros, we want a B customer, below 2500 a C customer is OK, too. Mmh. Should be no problem with a couple of gateways!"
+
+### Showing decision logic in the diagram?
+
+Diagram (BPMN):
+  start "Credit card application received" → service task "Determine application details" → exclusive gateway "Monthly credit?"
+    — [> 5000: =credit > 5000] exclusive gateway "Customer Category?"
+      — [A: =category = "A"] exclusive gateway → user task "Issue credit card" → end "Credit card application accepted"
+      — exclusive gateway → send task "Reject credit card application" → end "Credit card application rejected"
+    — exclusive gateway "Customer Category?"
+      — [A, B or C: =category = "A" or category = "B" or category = "C"] (back to exclusive gateway)
+      — (back to exclusive gateway)
+    — [> 2500: =credit > 2500] exclusive gateway "Customer Category?"
+      — [A or B: =category = "A" or category = "B"] (back to exclusive gateway)
+      — (back to exclusive gateway)
+
+When modeling business processes, we focus on the flow of work and just use gateways to show that following tasks or results fundamentally differ from each other. However, in the example above, the business analyst used gateways to model the logic underlying a decision, which clearly is considered to be an anti-pattern!
+
+It does not make sense to model the rules determining a decision inside the BPMN model. The rules decision tree will grow exponentially for every additional criteria. Furthermore, we typically will want to change such rules much more often than the process (in the sense of tasks needed to be carried out).
+
+### Using a single task for a decision
+
+Diagram (BPMN):
+  start "Credit card application received" → business rule task "Evaluate credit-worthiness" → exclusive gateway "Applicant credit-worthy?"
+    — [No: =not(creditWorthy)] send task "Reject credit card application" → end "Credit card application rejected"
+    — [Yes: =creditWorthy] user task "Issue credit card" → end "Credit card application accepted"
+
+**(1)**
+
+Instead of modeling the rules determining a decision inside the BPMN model, we just show a single task representing the decision. Of course, when preparing for executing such a model in Camunda, we can wire such a task with a DMN decision table or some other programmed piece of decision logic.
+
+**(2)**
+
+While it would be possible to hide the evaluation of decision logic behind the exclusive gateway, we recommend always showing an explicit node with which the data is retrieved, which then might be used by subsequent data-based gateways.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns

package/.llms/chunks/components.best-practices.modeling.modeling-with-situation-patterns.md

@@ -0,0 +1,8 @@
+# Modeling with situation patterns
+
+Document patterns that share common characteristics and find a satisfying solution for modeling them.
+
+When modeling, you will sometimes realize that some situations share common characteristics. To save work for yourself and spread such knowledge within your organization, collect and document such patterns as soon as you understand their nature and have found a satisfying solution for modeling them. For a start, we collected some typical patterns for you, which we observe quite often in our modeling practice. You do not need to reinvent the wheel over and over again.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-with-situation-patterns