@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.best-practices.management.doing-a-proper-poc.defining-a-scope-relevant-to-your-business-planning-the-technical-environment.md

@@ -0,0 +1,12 @@
+# Doing a proper POC — Defining a scope relevant to your business — Planning the technical environment
+
+Make the necessary technological choices. Typically, POCs _run on Camunda 8 SaaS_ unless your goal is to validate that Camunda 8 runs in your Kubernetes environment in a self-managed fashion. A simple test account is often sufficient, unless your goal is to do load or performance tests, for which you need bigger clusters. Reach out to us in such cases. If your POC includes [AI agents](https://docs.camunda.io/docs/next/reference/glossary#ai-agent), SaaS also gives you [Camunda-provided LLM](https://docs.camunda.io/docs/next/components/agentic-orchestration/camunda-provided-llm), so you can run them within a provided budget instead of setting up an LLM provider account first.
+
+To access _third party systems_ during your POC, set up proper test systems for those and verify that they are usable.
+
+Prepare a location in a _version control system_ where you can develop your POC. Having a shared repository with history does make sense also (or especially) in a 2-day POC! Collaboration is simplified if the Camunda consultant can also access that repository. It may be worth just creating a repository with weaker access limitations for the POC.
+
+If your organization cannot easily set up a repository for the POC, or access for externals is impossible, you can create a cloud repository. We typically recommend [GitHub](https://github.com/); a free account is sufficient. It gives you a Git repository and you can invite all necessary people for the POC. Afterwards, you can delete that repository.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/doing-a-proper-poc

package/.llms/chunks/components.best-practices.management.doing-a-proper-poc.defining-a-scope-relevant-to-your-business-selecting-the-time-frame.md

@@ -0,0 +1,11 @@
+# Doing a proper POC — Defining a scope relevant to your business — Selecting the time frame
+
+As already mentioned above, we typically plan no more than _a focused week_ for the POC workshop itself. Sometimes it also works well to split up the POC into two weeks of 2-3 days each, which allows everybody to reflect on the POC over the weekend.
+
+- Plan _1-3 days_ for _modeling_ the process with Camunda Modeler.
+- Plan _2-3 days_ for _implementing_ the process solution.
+
+When selecting the exact time frame, consider all the people involved, as well as any technical preparation you need to do up front. You also might want to plan for further steps, like a few more things you implement yourself internally in a second follow up week.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/doing-a-proper-poc

package/.llms/chunks/components.best-practices.management.doing-a-proper-poc.defining-a-scope-relevant-to-your-business.md

@@ -0,0 +1,17 @@
+# Doing a proper POC — Defining a scope relevant to your business
+
+Select a _useful_ and _suitable_ process, case, or decision given your goals.
+
+Typically, it should...
+
+- Be _relevant_ to your _core business_ stakeholders.
+- Make your organization's _return on investment_ on BPM more transparent.
+- Be _feasible_ within the POC time box.
+
+Avoid political mine fields when selecting the process for your POC.
+
+
+## Planning the POC
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/doing-a-proper-poc

package/.llms/chunks/components.best-practices.management.doing-a-proper-poc.defining-and-focusing-on-specific-goals.md

@@ -0,0 +1,16 @@
+# Doing a proper POC — Defining and focusing on specific goals
+
+Before planning and carrying out a POC, you should consciously clarify the specific goals you want the POC to achieve. Typical goals might be:
+
+- To _verify_ the approach or the tool works under specific circumstances.
+- To _show_ a case that _convinces_ internal stakeholders that the approach makes sense.
+- To work through a complete _example_ and get specific _questions_ sorted out.
+- To _learn_ about Camunda and _understand_ how it works.
+
+**Note**
+When selecting your goal, keep in mind the needs of all relevant stakeholders.
+
+Do not just "collect" goals here, but try to make up your mind as to what really matters. Often, it is better to make a clear choice. For example, whether to show off a nice user interface at the end of the week or to have time to clarify all questions and to understand Camunda in depth, maybe even only using unit tests.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/doing-a-proper-poc

package/.llms/chunks/components.best-practices.management.doing-a-proper-poc.md

@@ -0,0 +1,22 @@
+# Doing a proper POC
+
+When evaluating your process automation approach, a POC helps check if the method and technology suit your needs.
+
+When evaluating your process automation approach, a **proof of concept (POC)** is often a good step to check if the process automation methodology, the standards of BPMN and DMN, as well as the Camunda technology suit your needs. It is vital for a POC to make up your mind about your goals, to select a suitable process, and to prepare it and carry it out properly.
+
+
+## Understanding POC
+
+With a POC, you create a prototype application within no more than _three to five days_. The result of a POC is intended to be thrown away after having served its purpose: to try and show that your project will "fly" - including all aspects relevant for your specific situation. Such aspects might be:
+
+- Does Camunda _fit into your own architecture_?
+- Does the _development approach_ fit into your own organization's approaches?
+- How can you _model_ a specific business domain problem?
+- Which kind of _know how_ is needed for the business and development teams?
+- Which _effort_ will typically be needed for these kinds of projects?
+- What are the impacts of projects for _operations_?
+
+Often, it does make sense to implement such a POC together with Camunda, our partners, or specialized consultants to get quick results and focused feedback with respect to your specific challenges. However, you should always at least _co-develop_ the POC yourself to really understand what is going on. A team size of two to four people has proven to be quite optimal.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/doing-a-proper-poc

package/.llms/chunks/components.best-practices.management.doing-a-proper-poc.presenting-the-results.md

@@ -0,0 +1,45 @@
+# Doing a proper POC — Presenting the results
+
+Before presenting the results of your POC to a wider audience of stakeholders, select a _speaker_ who is comfortable with presenting, prepare a set of focused _slides_ illustrating your progress and the lessons learned, and _test_ your solution and presentation at least once up front.
+
+The speaker might also be your Camunda Consultant - they are used to presenting to a wide audience!
+
+
+## Checklists
+
+### Technical
+
+- _Cloud Access_: Make sure you have an account for Camunda 8 with an active subscription or trial account.
+
+- _Installations_: Make sure your _developer systems_, as well as any _target systems_ for the POC test and production you wish to use are set up. In particular install:
+  - Camunda _Modeler_ (https://camunda.org/download/modeler/)
+  - Java, Maven, and your favorite IDE (e.g. Eclipse)
+  - Make sure _Maven_ runs and builds and it can access all necessary dependencies. [Download and build this project](https://github.com/camunda/camunda-platform-tutorials/tree/main/quick-start/microservice-orchestration/worker-java) to verify that your build runs.
+
+- _Developer Computers_: For maximum productivity, all participating developers should use the computer with which they work every day. Avoid using computers from a training room or shared laptops unless they allow a remote connection to the developer's personal computer. If the developer's computers are neither portable nor remotely accessible consider conducting the POC in the regular office space of the developers. If your company network is restricting access to Maven and Git repositories on the internet, consider using laptops that are not connected to the company network. Similarly, you should not force the external consultants to work on one of your computers. They will be twice as productive on their laptops and not lose time with software setup, configuration, and access restrictions. Obviously, you do not have to connect the consultant's laptop to your company network. Internet access and a shared code repository are enough to collaborate.
+
+- _Files_ or _Version Control System_: Make sure we can easily exchange files and code during the POC, preferably via your own version control system (e.g. Git or SVN) or at least via shared folders, USB sticks, or email attachments.
+
+- _Interfaces_: Clarify which technical systems' interfaces you want to access during your POC, make any _documentation_ for those available to the whole POC team, and make sure there is a technically knowledgeable _contact person_ for the interface available to the team during the POC. Set up a _test system_ and verify that it is usable. Verify with Camunda that everything is clear to the team, in particular from a technological perspective.
+
+### Organizational
+
+Inform all POC team members and other relevant stakeholders about the following:
+
+- _Goals_ and the selected _scope_ for the POC
+- _Start_ and _end times_, as well as any additional preparation/meet-up times
+- _Names and roles_ of all involved _people_
+
+- For onsite POCs:
+  - Exact _location/address_ at which the POC is taking place as well as instructions about how to find together when arriving (for onsite POCs)
+  - _Projector_, white-board, and flip-chart availability
+  - _Internet_ availability for team members and external consultants
+
+- For remote POCs:
+  - Exact meeting setup. For example, links to the meeting room, passwords, etc. In case you can't easily host meetings for external participants, your Camunda consultant can setup a Zoom or Microsoft Teams call.
+  - Ideally, some chat capability (e.g. a temporary Slack account)
+
+Ideally, prepare a few _organizational_ and/or _project_ info slides to get everybody up to speed on day one of the workshop.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/doing-a-proper-poc

package/.llms/chunks/components.best-practices.management.following-the-customer-success-path.2.md

@@ -0,0 +1,16 @@
+# Following the customer success path — (2)
+
+**(7)**
+
+_Next processes_: Try to avoid doing too many projects in parallel in the beginning to allow new learning to influence your future work. If you have parallel pilots, organize knowledge sharing between the teams. Ideally, let the team of the first pilot directly implement a sequential process.
+
+**(8)**
+
+_Custom BPM Platform_: In bigger organizations, you typically try to set up your custom BPM platform, meaning a common infrastructure for all upcoming Camunda projects. Try to do as little of this as possible during the first pilot and start building the platform afterwards, taking all learnings into account. At the same time, do what is necessary for the pilot project itself or for other stakeholders to feel comfortable (e.g. Enterprise Architecture).
+
+**(9)**
+
+_Process architecture_: BPM initiatives often start by drafting a process landscape and capture all relevant processes of the company. Try to avoid this, and do as little as possible during your first pilot project. Maybe do a quick process survey to capture relevant processes (by name) to identify a good candidate for the pilot. Especially do not model all processes in your company in depth before you experienced an "end-to-end" project, including automation of Camunda yourself. Then, you will have gained a deeper understanding of methodology and value around BPMN and DMN.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/following-the-customer-success-path

package/.llms/chunks/components.best-practices.management.following-the-customer-success-path.estimating-effort.md

@@ -0,0 +1,50 @@
+# Following the customer success path — Estimating effort
+
+When starting your BPM project, it is often necessary to roughly estimate the expected effort. A process model can serve as a central artifact for estimation purposes. Avoid too fine-grained estimations as they typically are not worth the effort.
+
+However, on a management level one often must have some estimations to secure budgets, get projects started, allocate needed resources, and communicate expected time frames. The success factor is to do estimations _on a very rough level_ and avoid spending too much time with details. More often than not, the details develop differently than expected anyway.
+
+We often note customers successfully estimate _T-Shirt size categories (S, M, L, XL and XXL)_. Such an approach is sufficient for us to make roughly informed decisions about priority and return on investment.
+
+![T-Shirts](following-the-customer-success-path-assets/t-shirts.png)
+
+Having said that, your organization may demand that you _map_ such rough sizes to some measuring system already used; for example, _story points_ or _person days_. To preserve the rough character, consider mapping the sizes by using a series of sharply increasing numbers:
+
+| S   | M   | L   | XL  | XXL |
+| --- | --- | --- | --- | --- |
+| 2   | 5   | 13  | 50  | 200 |
+
+Much more important than concrete numbers is an educated gut feeling. Therefore, try to understand the influencing factors determining most of the effort by implementing your lighthouse process.
+
+### Using the process model for estimation
+
+A process model can be seen as a central artifact for estimation purpose, as it indicates and visually maintains a lot of the influencing factors mentioned above.
+
+Diagram (BPMN): Invoice Receipt
+  start "Invoice received" → user task "Assign Approver" → exclusive gateway → user task "Approve Invoice" → exclusive gateway "Invoice approved?"
+    — [No: =not(approved)] user task "Review Invoice" → exclusive gateway "Review successful?"
+      — [Yes: =successful] (back to exclusive gateway)
+      — [No: =not(successful)] end "Invoice not processed"
+    — [Yes: =approved] user task "Prepare Bank Transfer" → service task "Archive Invoice" → end "Invoice processed"
+  lanes: Team Assistant, Accountant, Approver
+
+Here are the figures you could estimate:
+
+1. Setting up development environment: **S**
+2. Modeling and understanding requirements: **L**
+3. Implementing the process solution:
+
+**(1)**
+**(2)**
+**(6)**
+
+4. Going live: **M**
+
+Using the process model, you can also foresee potential effort drivers, for example:
+
+- The legacy archive is really hard to integrate.
+- The tasks need to be integrated into an existing legacy task list, which might not be straight forward to do.
+- The metadata from the PDF shall be extracted, and a specialized form be shown to the user.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/following-the-customer-success-path

package/.llms/chunks/components.best-practices.management.following-the-customer-success-path.md

@@ -0,0 +1,47 @@
+# Following the customer success path
+
+Follow certain steps and Best Practices when evaluating and introducing process automation to help make it a success.
+
+Following certain steps when evaluating and introducing process automation helps to make it a success. Ensure you review the appropriate best practices at the right time.
+
+
+## Understanding the customer success path
+
+When introducing Camunda as a new process automation platform inside your company, the following process has shown to work best:
+
+Diagram (BPMN):
+  start → "Evaluate BPM potential"
+    — "Setup process architecture and landscape" → end
+    — "Evaluate products and select Camunda"
+      — "Identify "lighthouse" process" → intermediate throw event "Project prepared" → "Perform Proof of Concept (PoC)" → intermediate throw event "PoC implemented" → "Develop pilot" → "Prepare operations" → "Go live" → intermediate throw event "Pilot implemented" → "Review pilot" → "Improve "lighthouse" pilot" → intermediate throw event "Further develop- ment prepared" → "Implement next process" → end
+      — "Build custom BPM platform" → end
+  lanes: Process Architecture, Project, Enterprise Architecture
+  note: At first, do just enough to identify "lighthouse" process and to argue for BPM approach
+  note: Do as little as possible as late as possible!
+
+**(1)**
+
+_Evaluation_: Take the philosophy of the evaluated products into greater consideration than working solely with feature matrices. Practical experience can be invaluable. You might be interested in our [Whitepaper: "Camunda compared to alternatives"](https://page.camunda.com/wp-camunda-compared-to-alternatives).
+
+**(2)**
+
+_Process selection_: It is very important to select a suitable pilot process. Use a relevant process where you can show benefits of BPM including a Return on Invest (ROI) calculation. However, avoid too big or too "political" processes to minimize the risk of failure due to avoidable reasons. Note that you can use this process in the proof of concept (PoC) or select a different process for the first PoC, depending on the goals you have.
+
+**(3)**
+
+_Proof of Concept_ (PoC): Model the process to a high standard. It should be clear, understandable, and precise, as it will have a high visibility. Include necessary technical proofs, like calling real services in your environment. Include human tasks if your process where appropriate. We suggest using Camunda Tasklist as a first step to save effort in developing your own tasklist, unless a tasklist is important for your overall proof. Include "eye candies" like reporting to make non-technical stakeholders happy. Concentrate on the important aspects to do the proof and prepare to throw away the code afterwards to start fresh for the pilot, as it is very valid for early POCs to be "hacky" in order to keep focus on the end goals.
+
+**(4)**
+
+_Development_: Model the process with the same standard described for a PoC. It should be clear, understandable, and precise. Again, the reason for this is that it will be the most visible part of the project. Develop the project in an iterative manner to learn fast. Do proper testing to achieve a high quality.
+
+**(5)**
+
+_Operations_: Prepare for real operations, which includes setting up the real hardware as well as securing and monitoring the platform.
+
+**(6)**
+
+_Pilot review_ and _Pilot improvements_: Review the project after it has finished and gone live. Take some time to clean up, as the project normally serves as a "lighthouse" and "copy and paste" template for sequential projects, so it is worth the effort. It's better to plan time for this phase than try to make things perfect during early development, as you will have learned a lot once the pilot runs on the live system for a while.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/management/following-the-customer-success-path

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.ad-hoc-sub-processes.md

@@ -0,0 +1,9 @@
+# Building flexibility into BPMN models — Ad-hoc sub-processes
+
+The techniques above keep the sequence of activities fixed and use events to deviate from it. An [ad-hoc sub-process](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses) instead leaves the sequence open: its activities carry no sequence flow between them, and which of them run, in which order, and how often is decided at runtime instead of at design time.
+The decision can be made either by the engine, based on an expression in the model, or by a job worker. For example, if the subprocess hosts an AI agent, the AI Agent connector can make the decision.
+
+The symbols above still apply around and within an ad-hoc subprocess. You can use boundary events and [event subprocesses](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses#event-sub-processes) to interrupt or redirect it while it is running. Therefore, leaving the sequence open-ended does not mean giving up control over it.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.boundary-events-to-add-activities-on-triggers.md

@@ -0,0 +1,14 @@
+# Building flexibility into BPMN models — Boundary events to add activities on triggers
+
+BPMN allows us to attach events to the boundary of activities to trigger some follow-up action. By modeling such an event as either **interrupting** or **non-interrupting**, we can decide to do the activities either _instead of_ the activity we attach the event to, or _in addition to_ it.
+
+Diagram (BPMN):
+  "Carry out default activity"
+  boundary event "Something happens" → "Instead, carry out this activity"
+  "Carry out default activity"
+  boundary event "Some time elapses" → "In addition, carry out this activity"
+  note: We cancel this activity in case "something happens"
+  note: We continue this activity in case "some time elapses"
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.escalation-events.md

@@ -0,0 +1,25 @@
+# Building flexibility into BPMN models — Escalation events
+
+Sometimes we need highly flexible means to cancel scopes or trigger additional activities from within a scope. The BPMN escalation events can be particularly useful to implement such requirements.
+
+Diagram (BPMN):
+  start "..." → "..." → subprocess → "..." → end "..."
+
+**(1)**
+
+As soon as we are finished with the first activity inside the scope...
+
+**(2)**
+
+...we inform the surrounding scope about that and trigger an additional, essential activity...
+
+**(3)**
+
+...but also continue with our second activity to complete the subprocess.
+
+**(4)**
+
+We can then already continue with the follow-up work regardless of whether that additional activity is already finished.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.event-subprocesses.md

@@ -0,0 +1,11 @@
+# Building flexibility into BPMN models — Event subprocesses
+
+Sometimes we need to build in flexible activities which are carried out at any point in time. In such cases, we can leverage BPMN's event-based subprocesses.
+
+Diagram (BPMN):
+  start "..." → "Carry out a first activity" → "Carry out a second activity" → "Carry out a third activity" → end "..."
+  note: We cancel the whole process instance in case "something happens"
+  note: We continue the whole process instance in case "some time elapses"
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.examples.md

@@ -0,0 +1,50 @@
+# Building flexibility into BPMN models — Examples
+
+### Allow proactive order status communication
+
+Assume that for an order to be validated, the customer must determine the delivery date before we can confirm the order. If the order is not acceptable—due to consistency issues or customer related issues—it is declined.
+
+Some of our orders might be so important that we want to ensure we keep customers happy, even if not everything runs smoothly on our side.
+
+Diagram (BPMN):
+  start "Order received" → service task "Validate order" → service task "Check customer" → service task "Determine delivery date" → end "Order confirmed"
+
+**(1)**
+
+Order managers can request proactive customer communication on demand. Assume they can communicate the reasons via a form, whereas the communication as such is carried out by the call center.
+
+**(2)**
+
+On a regular basis, we check based on some rules, whether the order is so important that we proactively communicate why the order is not yet confirmed. Again, the communication is carried out by the call center.
+
+### Allow for order cancellation any time
+
+The customer might be allowed to request a cancellation until the order is confirmed. This request would have to be reviewed to determine whether we must accept the cancellation.
+
+Diagram (BPMN):
+  start "Order received" → service task "Validate order" → service task "Check customer" → service task "Determine delivery date" → end "Order confirmed"
+
+**(1)**
+
+Whenever the customer requests a cancellation until the order is confirmed, we review that request and decide whether we have to accept the cancellation or not.
+
+**(2)**
+
+If we accept the cancellation, we must terminate the entire process. To do so, we need to use one trick: throw an error event that will end the current event subprocess, but not yet the order process.
+
+**(3)**
+
+This leads to another subprocess to be triggered, and this one is interrupting. Now, the process instance is really cancelled.
+
+### Allow for order details to change, but repeat order validation
+
+**Caution: Camunda 7 Only**
+Condition events are [not yet supported in Camunda 8](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage)
+
+If the customer changes the order details, the order must be validated again.
+
+Diagram (BPMN):
+  start "Order received" → subprocess "Order Processing" → service task "Determine delivery date" → end "Order confirmed"
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.md

@@ -0,0 +1,13 @@
+# Building flexibility into BPMN models
+
+Sometimes we need ways to build flexibility into process models to deal with operational problems or to allow for humans to intervene.
+
+BPMN modeling primarily targets structured processes, often with the goal to automate as many steps as possible, increase efficiency, and decrease process execution costs. But sometimes we need ways to build flexibility into such process models to deal with expected or unexpected operational problems or to allow for humans to intervene.
+
+
+## Understanding the required symbols
+
+To build flexibility into BPMN process models, one must understand BPMN symbols and modeling techniques. After introducing the main symbols, we can demonstrate more concrete examples.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.subprocesses-with-boundary-events.md

@@ -0,0 +1,21 @@
+# Building flexibility into BPMN models — Subprocesses with boundary events
+
+By attaching boundary events not just to individual activities, but also to subprocesses, we can flexibly define the area or scope for which we want to trigger some flexible activities.
+
+Diagram (BPMN):
+  start "..." → "..." → subprocess → end "..."
+
+**(1)**
+
+While we are occupied with carrying out some area of activities, in a scope of our process...
+
+**(2)**
+
+...an event might occur, which causes us...
+
+**(3)**
+
+...to carry out this activity in addition to continuing with ordinary work.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.terminate-end-events.md

@@ -0,0 +1,17 @@
+# Building flexibility into BPMN models — Terminate end events
+
+To build flexibility into process models, it is also useful to remember that the termination end event just terminates the scope within which it is defined and therefore _not_ always the whole process instance. With that technique, it becomes possible to cancel some activities inside a subprocess while completing it successfully and leaving it via the typical outgoing path.
+
+Diagram (BPMN):
+  start "..." → "..." → subprocess → "..." → end "..."
+
+**(1)**
+
+As soon as one of our two activities achieves the result, we can cancel the other one...
+
+**(2)**
+
+...and successfully complete the subprocess and normally continue with our follow-up work.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.building-flexibility-into-bpmn-models.use-events-as-triggers.md

@@ -0,0 +1,11 @@
+# Building flexibility into BPMN models — Use events as triggers
+
+BPMN events allow us to react to all kinds of information. We can use them to trigger flexible activities. In particular, BPMN events **catching** **messages**, **conditions**, and **timeouts** are useful in that context.
+
+Diagram (BPMN):
+  intermediate catch event
+  intermediate catch event
+  intermediate catch event
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/building-flexibility-into-bpmn-models

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.knowing-the-dmn-hit-policy-basics-multiple-result-decision-tables.md

@@ -0,0 +1,15 @@
+# Choosing the DMN hit policy — Knowing the DMN hit policy basics — Multiple result decision tables
+
+**Multiple result** tables may return the output of multiple rules. The hit policies for such tables are:
+
+- `C`**ollect**: All matching rules result in an arbitrarily ordered list of all the output entries.
+
+- `R`**ule order**: All matching rules result in a list of outputs ordered by the sequence of those rules in the decision table.
+
+- `O`**utput order**: All matching rules result in a list of outputs ordered by their (decreasing) output priority.
+
+**Note**
+Camunda does not yet support the hit policy **output order**. In essence, output orders are specified as an ordered list of output values in decreasing order of priority. Such priorities are therefore independent from rule sequence! Though not yet supported, you can mimic that behavior using hit policy "(**C**)ollect" and determining an output order yourself; for example, by means of an execution listener attached to the end of your business rule task.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.knowing-the-dmn-hit-policy-basics-single-result-decision-tables.md

@@ -0,0 +1,24 @@
+# Choosing the DMN hit policy — Knowing the DMN hit policy basics — Single result decision tables
+
+Such tables either return the output of only one rule or aggregate the output of many rules into one result. The hit policies to be considered are
+
+- `U`**nique**: Rules do not overlap. Only a single rule can match.
+
+- `F`**irst**: Rules are evaluated from top to bottom. Rules may overlap, but only the first match counts.
+
+- `P`**riority**: Rule outputs are prioritized. Rules may overlap, but only the match with the highest output priority counts.
+
+**Note**
+Camunda does not yet support the hit policy **priority**. In essence, priorities are specified as an ordered list of output values in decreasing order of priority. Such priorities are therefore independent from rule sequence! Though not yet supported, you can mimic that behavior using hit policy "(**C**)ollect" and determining a priority yourself; for example, by means of an execution listener attached to the end of your business rule task.
+
+- `A`**ny**: Multiple matching rules must not make a difference: all matching rules must lead to the same output.
+
+**Collect** and **aggregate**: The output of all matching rules is aggregated by means of an operator:
+
+- `C+`**Sum**: Add up all the matching rule's distinct outputs.
+- `C<`**Minimum**: Take the smallest value of all the matching rule's outputs.
+- `C>`**Maximum**: Take the largest value of all the matching rule's outputs.
+- `C#`**Number**: Return the number of all the matching rule's distinct outputs.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.knowing-the-dmn-hit-policy-basics.md

@@ -0,0 +1,24 @@
+# Choosing the DMN hit policy — Knowing the DMN hit policy basics
+
+A decision table consists of several **rules**, typically represented as rows. When reading such a row, we look at certain **input values** and deduct a certain result represented by **output values**. When using the simplest hit policy **"unique"** (**U**), such rules do **not overlap**: only a single rule must match.
+
+**(1)**
+
+We define an "input" value **season** here. For every single season ...
+
+**(2)**
+
+... there is a **jacket** defined we want to use, the "output" of the rules here.
+
+**(3)**
+
+The hit policy "**Unique**" (indicated by the character **U**) enforces that rules do **not overlap**: only a single rule must match.
+
+Now consider that we build a decision table with **overlapping rules**. In other words, that means more than one rule may match a given set of input values. We then need one of the **alternative hit policy** indicators to unambiguously understand the decision logic according to which such rules are interpreted.
+
+The hit policy **indicator** is a single character shown in the decision table's top left cell, right beneath the decision's name. The character is the initial letter of one of the defined seven hit policies `U`**nique**, `A`**ny**, `P`**riority**, `F`**irst**, `C`**ollect**, `O`**utput order** and `R`**ule order**. Furthermore, the hit policy 'Collect' may also be used with one of four aggregation operators, actually giving us four more hit policies `C+` (**Sum**), `C<` (**Minimum**), `C<` (**Maximum**) and `C#` (**Number**).
+
+Eight of those eleven hit policies evaluate a decision table to a **single result**. Three hit policies evaluate a decision table to **multiple results**.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.md

@@ -0,0 +1,8 @@
+# Choosing the DMN hit policy
+
+Hit policies describe different ways (standardized by DMN) to evaluate the rules contained in a decision table.
+
+**Hit policies** describe different ways (standardized by DMN) to evaluate the rules contained in a decision table. Different hit policies do not only lead to different results, but typically also require different modes of thinking and reason about the meaning of the entire table. Therefore, it's crucial to not just know the different DMN hit policies, but also to understand the motivations for their existence and the most typical cases for using them.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.understanding-dmn-hit-policy-use-cases-collect-deciding-which-groups-of-people-may-review-an-order.md

@@ -0,0 +1,12 @@
+# Choosing the DMN hit policy — Understanding DMN hit policy use cases — Collect: deciding which groups of people may review an order
+
+With hit policy **collect**, you do not care about the order or any interdependencies between your rules at all. Instead, you just "collect" independent rules and care about the question which rules are applicable to your specific case.
+
+Consider, for example, the question of "who is allowed" to carry out some action, as, for example, reviewing and deciding about incoming orders:
+
+As a result of this decision table, we will either get `["Sales"]` or `["Management"]` or a list of both groups `["Sales", "Management"]`.
+
+We could use this information to route the order into the applicable group's task lists or control access rights of a configurable software solution, etc. Of course, you could at any time introduce more rules and eventually also differentiate between more groups without changing your software solution.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.understanding-dmn-hit-policy-use-cases-first-accepting-a-customer-based-on-hard-criteria.md

@@ -0,0 +1,22 @@
+# Choosing the DMN hit policy — Understanding DMN hit policy use cases — First: accepting a customer based on hard criteria
+
+Having said that, the hit policy "**First**" can sometimes make it easier for an organization to reason about decision logic dealing with some criteria that are "harder" (more "clearcut") than others. Furthermore, it can help to make a decision table layout more compact and therefore easier to interpret.
+
+**(1)**
+
+Assume that everybody in the organization knows that first rule: "Once on the blocklist, never again accepted." The layout and the hit policy of the decision table therefore supports the organization's way of doing business: once we know that single fact about a customer, we don't need to think further.
+
+**(2)**
+
+The following rules from row 2-4 are expressed in an "Accept" manner and might change more often over time. The organization's way of thinking is literally "from top to bottom". Once we find an acceptance rule, we can deal with the customer.
+
+**(3)**
+
+For execution in a decision engine, don't forget to add a rule not accepting any other customers as a last row.
+
+In scenarions dealing with **hard** **exclusion** and **inclusion** criteria, we often don't care that much if the rules overlap, but prefer to argue about very clearcut cases first and about more sophisticated ones later on. Furthermore, the organization's way of thinking and doing business might be better supported by a decision table using the hit policy **First**.
+
+Our experience so far tends to show that it can be more tricky and error prone to argue about a **First** hit policy decision table than it might occur to you at first sight. Therefore, be especially careful and always test your logic in case you are dealing with sensitive business!
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.understanding-dmn-hit-policy-use-cases-sum-accepting-a-customer-based-on-soft-criteria.md

@@ -0,0 +1,28 @@
+# Choosing the DMN hit policy — Understanding DMN hit policy use cases — Sum: accepting a customer based on soft criteria
+
+Hit policy "collect" may be combined with operators such as **Sum (C+)**, leading to very different use cases. A very typical one is the requirement to evaluate a case based on manyfold factors influencing the overall result.
+
+Assume, for example, that we want to deal with customers we know nothing about. They receive a score of 0. But in case we know something about them, we also weigh in our knowledge:
+
+**(1)**
+
+The overall creditworthiness is deducted by throwing in many factors.
+
+**(2)**
+
+Here, for example, we give credit in case we made good experiences with the customer in the past.
+
+**(3)**
+
+A very low current income does not matter as long as the customer is not a stranger to us!
+
+**(4)**
+
+On the other hand, as soon as a customer has proof for a good income, they receive five points for "reasonable" income as well as 10 points extra for good income.
+
+Even if we had bad experience with a customer (which means they start from -15), we end up with an overall score of 0 in case the customer has a good income now, and start to accept the customer again.
+
+In scenarions dealing with **soft exclusion** and **inclusion** criteria, we need a mechanism to associate a weight to different scenarios. This is ideally supported by hit policy **Sum (C+)**.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.understanding-dmn-hit-policy-use-cases-unique-granting-categories-of-customers-a-specified-discount.md

@@ -0,0 +1,16 @@
+# Choosing the DMN hit policy — Understanding DMN hit policy use cases — Unique: granting categories of customers a specified discount
+
+Hit policy "**Unique**" will typically make it easy to build a decision table, which ensures your rules are "complete" - in the sense that the rules do not just not overlap but cover all possible input values - so that you do not "forget" anything.
+
+**(1)**
+
+The _input_ area of each row specifies a certain **segment** of possible input values.
+
+**(2)**
+
+This row, for example, expresses that _long time silver customers receive a 9% discount_.
+
+Such a use case fits to the hit policy "**Unique**". For such use cases, it is an advantage that this hit policy make your decision logic invalid in case you violate its requirement that your table rules never "overlap": after all, you must not produce ambiguous results.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy

package/.llms/chunks/components.best-practices.modeling.choosing-the-dmn-hit-policy.understanding-dmn-hit-policy-use-cases.md

@@ -0,0 +1,6 @@
+# Choosing the DMN hit policy — Understanding DMN hit policy use cases
+
+Most situations can be addressed using different hit policies. In that case, the hit policy will have an effect on the readability and maintainability of the table. Often it is worth trying different varieties until you have a feel for what will work best.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-dmn-hit-policy