Both elements are extensions to the BPM 2.0 standard and were introduced in Bizagi starting with version 11.0
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:
SELECT
a1.NAME AS TableName,
a2.name 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
FROM
sys.tables a1
INNER JOIN
sys.indexes a2
ON
a1.OBJECT_ID = a2.object_id
INNER JOIN
sys.partitions a3
ON
a2.object_id = a3.OBJECT_ID
AND a2.index_id = a3.index_id
INNER JOIN
sys.allocation_units a4
ON
a3.partition_id = a4.container_id
WHERE
a1.NAME NOT LIKE 'dt%' AND
a2.OBJECT_ID > 255 AND
a2.index_id <= 1
GROUP BY
a1.NAME, a2.object_id, a2.index_id, a2.name
ORDER BY
DataSpaceMB
--OBJECT_NAME(a2.object_id) Conclusion
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).
SELECT COUNT(*) FROM BADATATRIGGEREXECUTIONLOG
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.