> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/proces-biznesowy/tworzenie-procesu-biznesowego-w-bpmn-2.0/dobre-praktyki.md).
# Best practices
| Rule | Rule description |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Language | In the absence of top-down agreements in the names of tasks, subprocesses, events, and gateways, we use Polish.
Name variables according to the convention adopted in a given application (in Polish or English).
|
| Capitalization | Start names with a capital letter, and write the following words in lowercase (e.g. “Document verification”).
Proper names and acronyms are exceptions. Lack of consistency (e.g. using lowercase once and uppercase another time) will make it harder to quickly recognize process elements.
|
| Avoid technical terms | Instead of using classes or methods from code, use language understandable to the business.
Unclear or overly technical names can mislead, e.g. instead of “Verify documents” the use of “ExecuteDocumentCheck” makes the process harder to understand for non-technical people.
|
| Consistency of verbs in activity names | Use a consistent verb form in activity names in the process. For example, choose between infinitives (“Approve documents”) and personal forms (“Approving documents”) and apply them consistently throughout the model. |
| Precision and unambiguity | Make sure the name accurately reflects the given part of the process in the business context. Avoid ambiguous names that can be interpreted differently by different people. For example, instead of*Request handling*” it is better to use “*Transaction complaint registration*”. |
| - Description of gateway conditions
| Use unambiguous gateway descriptions, e.g. *“Yes”* / *“No”*. Avoid long, unnecessary descriptions and the use of technical terms such as *“True”* / *“False”*. |
| - Description of the start and end events
| If possible, use more precise names for the start and end elements of the process than *“Start”* and *“End”* (they do not indicate the circumstances of the start or end of the process). |
| 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 mistakes. However, try to avoid such names whenever possible (see the rule above). |
| Avoiding abbreviations | Avoid abbreviations, e.g. Instead of using the abbreviation "*Contract appr.*", it is better to write the full form "*Contract approval*". |
| Status names | If possible, use a single standard for status names (businessStatus) that takes the business context into account. |
More information:
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` 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=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.