Hi guys,
I am a new member of the analyst community and I have 2 questions for you, more experienced colleagues The questions came after the person who “teaches” stated that using attached-to-boundary events is a last resort, and she never does it. Strong doubts arose in me as to her competence. I have been learning BPMN for 3 weeks only and I have an overwhelming impression that I have already asked her many questions that she could not answer and had to consult with other people. That is why I am asking you for help, because asking other teachers with this question may not look nice. Especially because I learn the BPMN for 3 weeks now…
First, briefly the context:
This is one of the subprocesses in the lending company. The person submitting the form indicates whether he or she is possibly interested in home insurance in the event of a loan being granted. After successfully passing several verification steps, the employee must prepare a package together with an insurance quote. If the client is interested in the insurance, the employee prepares the insurance quote, then prepares the loan agreement and together sends them by e-mail to the client. The client then has 2 weeks to respond.
Question 1:
Is the attached-to-boundary conditional event properly used here?
In my opinion, when the token reaches task “Prepare acceptance pack”, the alternative “Prepare home insurance” route is activated (only if the client was interested), then after completion, the token returns to task again, an “Acceptance pack” is prepared and then an e-mail is sent to the client. At this point, the token jumps to the next task. The ‘teacher’s’ opinion: conditional even requires very many variables to be used, and it is a mistake to use it here. It is appropriate to use inclusive split (+merge).
Question 2:
Is the attached-to-boundary timer event properly used here?
In my opinion, the timer starts counting down as soon as the token appears in the task, and receiving an email from the client (within 2 weeks) causes the token to jump to the next task. The ‘teacher’s’ opinion: The timer will start counting down as soon as an email is received from a client, so an alternate path can never be activated. Only the event-based gateway is right here.
Guys, can you please provide me with some clear explanation?
This is something i would strongly disagree with. boundary events are fundamental to using BPMN in any real life scenario.
This mostly depends on how exactly the information that triggers the conditional event is sent, if the process starts with the data you need to trigger it, it’ll work the way you suggest but i would say in this case it makes the model harder to read and it would also not be able to do the work in parallel. I think the suggestion to use and including gateway would make more sense here because it would be more efficient and easier to follow.
Indeed - the timer starts as soon as the token reaches the activity that the timer is attached to. So I think in this case what you’ve modeled makes perfect sense.
Ad. Q1
You’re right Niall, if there’s like another department one for home insurance and another for the loan adquisition, would be more optimal to go in parallel, so in this case inclusive split. But hipotetically, if there was just one person to do both, so first one taks- and then another - would it be still correct to model it this way to keep track on one token only? - the home insurance is always volountary.
I would like to highlight some points regarding Q1
I am wondering why preparing pack task is represented as Send Task whereas preparing home insurance is represented as User Task.
Send Task is used to represent sending a message which is an instant action so attaching conditional boundary event to it doesn’t make sense.
The reader would understand this snip as following, while preparing acceptance if client shows interest in home insurance then prepare home insurance whereas as per the description, the client is supposed to show his interest in home insurance on application submission.
I like this kind of dialog, especially while learning new things
So, you do read it correctly. This is only a piece of a bigger process naturally and yes, the client must express his or her interest at the very beginning while apllying for the loan, but only if he passes the verification steps it is taken into account here. (If the client is rejected in earlier steps, we don’t come to this point at all.)
Why I chose Send Task instead of User T? Basically the client is supposed to receive 1 email only, the full package of information, a quote and a contract to sign. I know that I could have used 2 separate tasks (or more, but working on complex process it comes in handy using attached-to-boundary events to make it more compact, “less is more”). The difference between an Intermediate Send Event and the Send Task here is, that you are able to add more implementation steps in the work instruction - here the officer needs to get all documents together before sending an email and not only click on the ‘send’ button. The other task is an User Task, 'cause there’s only intern paper/computer work to do. So once the client showed his interest in the insurance (at the beginning), has positively past the check for his eligibility, he must receive one big pack with all information. The officer is obliged to work on the insurance quote first, as it has an impact on the contract terms - this is actually why the first task is interrupted. If the quote is ready, the officer can work on the acceptance pack and finally send an email. It is true, as @Niall said: chosing the including gate was better to let the work go in parallel if there were 2 person for this task. In this case only one person makes all this paper work.
I might be wrong, but I thought that the instant action is the Intermediate Send Event rather than the Send Task, and here we can add more implementaion steps.
Figured I’d poke my nose in this with a little comment.
Q1 I agree it is absolutly doable and at times the best way to design your flow BUT it does require you to think and know what you are doing.
The condition is evaluated EVERYTIME you reach the task so if you have a simple condition “customerInterested == True” then you need to make sure customerInterested is set to False sometime before you return to “prepare acceptance pack” or you will be stuck in a loop, noone wants to be stuck in a loop, there are scary creatures there.
If you have a tasklistener configured to the task it is also executed EVERYTIME so even if you manage to keep out of the loop it will run your listener twice.
The engine doesnt care if its the boundary event or sending a message that ends the task or if it has run any logic in it. Meaning if you look at a executed process in history it will show 2 completed “prepare acceptance pack”. So if you should wake up in the middle of the night and think “I need to know how many messages have been sent” and thinking “I can just count number of executed send tasks” you might end up with a number that is way off.
So yes do it if it is the best way but be carefull and think it through.
This is actually what I was the most afraid of… the “dead-loop” and those creatures… But thanks to the right mechanism the process can get through.
To be honest I dindn’t think about this, thanks! But hey, @JarlSeverin , the status wouldn’t be ‘interrupted’ instead of completed? I’m not yet working on the engine, ssso much more to learn!
So far I’m looking for the right balance between an exhaustive model and a compact one.
The questions came after the person who “teaches” stated that using attached-to-boundary events is a last resort, and she never does it. Strong doubts arose in me as to her competence. I have been learning BPMN for 3 weeks only and I have an overwhelming impression that I have already asked her many questions that she could not answer and had to consult with other people. That is why I am asking you for help, because asking other teachers with this question may not look nice. Especially because I learn the BPMN for 3 weeks now…
but aye you are correct. The main point is that any mechanism that reacts to the create event of the task will fire.
and those creatures… But thanks to the right mechanism the process can get through.