Bitrix24 Self-hosted administration

Workflows is a very important tool that allows automating company workflows. However, handling workflows requires a specific skill and must be exercised with caution. Otherwise workflows will create an excessive load on the project.

Several accounts operate simultaneously at the each physical Bitrix24 server. Excessively high load on a single server will negatively affect the rest of servers. Workflows can be one of such reasons Attention! To prevent such situations, technical restrictions were imposed on the number of launched workflow instances: no more than 2 (two) workflows allowed. It means, there could be many running workflows in total, but for no more than 2 (two) workflows for an individual element. . Due to this, it's recommended to check and correct your workflows. When an excessive load from workflows is detected, the account is blocked according to the licence agreement item 8.1.

Common mistakes

Below is the overview of the most common mistakes occurring when designing workflows, increasing load on the individual account:

1. Modifying different element fields using multiple actions — quite a frequent mistake Incorrect element editing:
   . Of course, you can edit each element field by a separate action. However, it significantly increases number of executed queries for a workflow in progress. It's recommended to modify all necessary element fields within a single action Here's how to edit an element:
   at one time.

2. Looping — carefully check the workflows for a created loop, especially, when using pauses. When running workflow for creating an element with loop exit condition error, a significant number of workflow instances launched for different elements is accumulated quite soon. Such issues occurring for workflows that edit elements is even more dangerous. In such case, even a small number of elements can accumulate a significant number of running workflows very quickly.
   In some cases, it's better to design a separate condition for loop termination. It ensures a loop exit, even if the main condition was not executed in due time/loops for some reason.

3. Using status check in a loop with pause. Sometimes, instead of Waiting for deal stage Action stops workflow execution until reaching a target deal stage.
   workflow uses loop with pause . In this case, workflow that creates elements accumulates a significant number of running workflows for various elements. With constant pausing and de-pausing, they create load and can lead to project being inoperable. In this case, its better to use the action Waiting for deal stage . The workflow will become operational only after element changes status to a required without creating excessive load during the rest of running time.

4. Incorrect use of pauses and assignments: this issue occurs frequently for workflows, launched when editing an element .

   Using such actions can disturb workflow format and integrity. While the workflow awaits until such actions are executed, the source element can be modified again. That's why workflows, launched to edit must be executed without any pauses or standbys and be terminated. In case when the workflow, launched for edit - contains pauses, action listening, data requests, you can surely say that the workflow runs incorrectly.

5. Listening for Parallel Event errors. Quite often, handling of this structure Allows directing workflow via different scenarios depending on the earliest event.
   encounters some issues. When employed, workflow is executed via the branch that follows after the first executed Action. However, if none of the actions have been completed, the workflow will be suspended and won't be executed further. To avoid this, always add a branch, containing Execution pause This action allows delaying the next action for a specified period of time . This way, the workflow Adding Execution pause into Parallel Events
   will continue running until time specified inside it expires, even of none of the actions are executed.