Start free

Typical mistakes in business processes creation

Bitrix24 business processes help to automate company processes. In this article we will try to list some of the typical mistakes newbies usually make in Bitrix24 when adding new business process, which may result in serious system overload. Each of Bitrix24 “physical” servers has a definite number of active portals running simultaneously. When one of this portals starts to suffer from overload, other server’s portals are affected as well.

To avoid such server overloads we are obliged to implement the following restriction regarding running business processes – no more than 2 running processes per CRM record. It means that you may have several running business processes but there must be no more than 2 for each particular CRM record.

Important: we recommend to check your running processes due to restriction mentioned above. Please note that we may deactivate your Bitrix24 portal in case of server overload caused by business processes running on your instance (see Bitrix24 Terms of Service).

Please find most typical mistakes in new business process creation below:

1. When modifications in a particular CRM record’s parameters are forced by several action blocks in your business process - CRM record’s modifications must be performed in frames of one action, as this will reduce the number of database queries caused by a running business process.

Sample A: incorrect modifications in CRM record forced by 2 business process action blocks.

Sample B: Correct CRM record modifications forced by one business process action block.

2. Endless process loop – it is very important to check possible process loop, especially if the process use pauses – in this case the process won’t be crashed during execution and you can simply miss errors. But in case you launch a CRM record’s creation business process template with error in loop construction exit condition, it will result in accumulation of processes elements launched for several CRM records.

Even more dangerous scenario is when the process is launched for CRM record’s modifications when contacting error in loop construction exit condition. In this case you can accumulate a big number of running processes in short time even based on small number of CRM records.  That’s why it is important to add special condition for process loop exit, which will ensure that the process is finished when the main condition hasn’t helped within  the required time (cycles).

For example, when the process’ loop construction contains a special condition (e.g. lead processing time is less than 1000 hrs) -   the process will be finished even when the lead status hasn’t changed yet. It helps to avoid endless process loop (e.g. when the lead's responsible person has been dismissed and there is nobody to take care of this particular CRM record).

Sample C - business process with additional condition for loop execution finish.

3. When you use status check in loop construction with a pause execution – this is common mistake, when instead of waiting for deal stage - a loop construction with pause execution is used. In this case when such process is used for CRM records creation, it will result in accumulation of processes elements launched for several CRM records. When cycling from pause back such process creates an excessive server overload and may result is your portal crash.

Sample D – incorrect usage of loop construction with pause while waiting for CRM record’s status.

Sample E - correct usage of waiting for deal status action – in this case the process will be activated only when deal status is changed, meaning it won’t needlessly load the system.

4. Business processes for CRM records modification with pause execution, actions and tasks – when a business process consists of some actions, waiting for data or pause execution – it may disrupt business process ideology and integrity, meaning while the process will be waiting for particular data - the initial condition of the CRM record may be changed (CRM record can be manually modified). That’s why CRM records modification processes must be launched without waiting for data & pauses and be finished in time.

If the process launched for CRM record modification contains waiting for data actions or pauses – we can already consider it as working incorrectly.

5. Parallel execution construction – when this construction is used the process will be going through the process line which follows the command that has been executed first. If none of the commands has been executed then the process will remain hanging unfinished. To avoid this always add process line with pause execution command. The process will continue execution after a set time period even if none of the main commands has been executed.

This helped
Thanks :)
Article feedback
This didn't help
Sorry :(
Could you please tell us why:
Article feedback
I still have questions