Bizagi Tips and Tricks

Don’t use Conditional activity or Conditional event

Both elements are extensions to the BPM 2.0 standard and were introduced in Bizagi starting with version 11.0

Conditional event

What is a Conditional activity

As Bizagi defines it, Conditional activities are enabled or disabled during the course of a case instance depending upon a business condition. They represent a user task that when enabled is allocated to an end-user.

What is a Conditional event

Similar to the Conditional activity, Conditional events are enabled as soon as a token arrives at them but will wait until a condition is met to move on to the next step in the process flow. They do not have a user interface, and they are not allocated or available for end-users.

My experience using both elements

When these two elements were introduced in Bizagi v11, I was happy because these were fixing a problem I had with other processes and now a solution was provided.

As a standard for all of the processes I design, I take into consideration the fact that the instance of the process should be cancelled at some point or someone should have the possibility to terminate the instance. And I am talking about the business users. Otherwise, as an Administrator is quite easy to terminate a case.

The above flow was designed with the following idea in mind: give the business user the option to cancel the case and also disable this option after the case reaches a particular state (where the case should not be cancelled anymore).

Like in this example, the cancel option is available until the Register Individual task is completed. Once the task is pushed forward and other users are involved in the process, we want to disable this option.

This also works for the time when the user starts a case by mistake and instead of getting in touch with the Administrator, they can cancel the case themselves. Of course, this could be fixed with a simple start form but the point here is that in some cases we can’t use a start form, and also you would like to have the Cancel option available until a particular business condition is met.

Why I am not using the Conditional event anymore

Recently, on one of my projects, I noticed how the size of the database was growing day by day. After some investigation, I discovered how a particular table took the most part of the space. The table is called BADATATRIGGEREXECUTIONLOG and on this particular project, it had 28 million records.

To get the size of each object I ran this script in the database:

	a1.NAME AS TableName, AS indexName,
	SUM(a3.rows) AS RowCounts,
	SUM(a4.total_pages) AS TotalPages, 
	SUM(a4.used_pages) AS UsedPages, 
	SUM(a4.data_pages) AS DataPages,
	(SUM(a4.total_pages) * 8) / 1024 AS TotalSpaceMB, 
	(SUM(a4.used_pages) * 8) / 1024 AS UsedSpaceMB, 
	(SUM(a4.data_pages) * 8) / 1024 AS DataSpaceMB
	sys.tables a1
	sys.indexes a2 
	a1.OBJECT_ID = a2.object_id
	sys.partitions a3 
	a2.object_id = a3.OBJECT_ID 
	AND a2.index_id = a3.index_id
	sys.allocation_units a4 
	a3.partition_id = a4.container_id
	a2.OBJECT_ID > 255 AND  
	a2.index_id <= 1
	a1.NAME, a2.object_id, a2.index_id, 


Every time the Scheduler runs and checks the business condition for the conditional event a new record is inserted into the BADATATRIGGEREXECUTIONLOG table. So imagine you have 10-15 processes and each of these has one Conditional event or at least one Conditional activity. No wonder my database was 9GB in size (after cleaning, the database had only 258MB).


And yes, all the Bizagi triggers are managed by the Scheduler, so this will have a performance impact on the Scheduler as well.

I do recommend using these as long as you don’t use them everywhere. Like one or two conditional events per project. Also, keep a close look at the database because if something goes wrong you will get quick feedback from the end-users. “The application is too slow. Please do something…”

If you would like to find out more about Bizagi please send us an email.