# Best practices

| Rule                                                     | Rule description                                                                                                                                                                                                                                                                                          |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Language                                                 | <p>In the absence of top-down decisions regarding task, subprocess, event, and gateway names, we use the Polish language.<br>Name variables according to the convention adopted in a given application (in Polish or English).</p>                                                                        |
| Capitalization                                           | <p>Start names with an uppercase letter, and write subsequent words in lowercase (e.g. <em>"Document review"</em>).<br>Exceptions are proper names and acronyms. Inconsistency (e.g., sometimes using lowercase and other times uppercase) will make it harder to quickly recognize process elements.</p> |
| Avoiding technical terms                                 | <p>Instead of using classes or methods from code, use business-friendly language.<br>Unclear or overly technical names can be misleading, e.g., instead of <em>"Verify documents"</em> using <em>"ExecuteDocumentCheck"</em> makes the process harder to understand for non-technical people.</p>         |
| Verb consistency in activity names                       | Use a consistent verb form in activity names throughout the process. For example, choose between infinitives ("Approve documents") and personal forms ("Approving documents") and apply them consistently across the entire model.                                                                        |
| Precision and unambiguity                                | Make sure the name accurately reflects a given part of the process in a business context. Avoid ambiguous names that may be interpreted differently by different people. For example, instead of "*Handling a request*" it is better to use "*Registration of a transaction complaint*".                  |
| <ul><li>Gateway condition descriptions</li></ul>         | Use unambiguous gateway descriptions, e.g. *"Yes"* / *"No"*. Avoid long, unnecessary descriptions and the use of technical terms such as *"True"* / *"False"*.                                                                                                                                            |
| <ul><li>Description of the start and end event</li></ul> | If possible, use more precise names for the starting and ending elements of the process than *"Start"* and *"End"* (they do not indicate the circumstances of the process start or end).                                                                                                                  |
| Version numbering of process steps                       | If the process contains steps with similar names, add version or step numbering, e.g. "*Document verification 1*" and "*Document verification 2*", to avoid confusion. However, try to avoid such names whenever possible (see the rule above).                                                           |
| Avoiding abbreviations                                   | Avoid abbreviations, e.g. instead of using the abbreviation "*Agreem. approval*", it is better to write the full form "*Agreement approval*".                                                                                                                                                             |
| Status names                                             | If possible, use one standard for status names (businessStatus) that takes the business context into account.                                                                                                                                                                                             |

More information: <https://blog.consdata.tech/2025/01/27/wstep-do-tworzenia-czytelnych-modeli-bpmn.html>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/proces-biznesowy/tworzenie-procesu-biznesowego-w-bpmn-2.0/dobre-praktyki.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.