Timer Boundary Event + Condition

BPMN & Modeling Discussion & Questions
1

We would like to model a Task with several timer boundary events which should only be enabled when a logical condition, based on a process variable, has a specific value.

In the attached (simplified) bpmn the task “verify incoming payment” should have 4 exits:

  • manual exit if the user decides to sent the dunning letter regardless of all timers
  • timer to sent first dunning letter after seven days if first dunning letter not already sent and payment not received
  • timer to sent second dunning letter after fourteen days if first dunning letter already sent and payment not received
  • timer cancel sales after four weeks if no payment received

Is there any way to model conditions in the timer boundary event only?SendInvoiceAndCheckIncomingPayment.bpmn (12.9 KB)

2

Hi,

Here’s an alternate approach. I changed one of the timers to be non-interrupting and repeat twice every 7 days. Hence I could remove one of the timers.

By not exiting the user task, you can have an interrupting timer at 4 weeks.

I added a non-interrupting escalation event to enable a user to initiate the equivalent of the reminder timer…

I also removed the terminate end events as an end event is all thats required.

There are other ways to achieve this, however here’s one example approach…

regards

Rob

SendInvoiceAndCheckIncomingPayment.bpmn (9.9 KB)

3

Hi Rob,
thank you for your proposal. It definitely makes the process easier and more readable.
But if I understood your solution correctly, It does not adress the requirement to fire the timer only, if the dunning letter is not already sent.
Maybe I lack some general understanding of the semantics of timers and manual escalation:

  • Does using a non interrupting timer or manual escalation mean, that the original token stays at the human task?
  • will all timers be cancelled if the human task is executed i.e. in this example goes to sales finished?

Thanks
Wolfgang

4

Hi Wolfgang,

Yes I was not sure if you send duplicate letters. An easy fix is this is a good example of process state. So the send letter task could set a process variable indicating the letter has been send. Then a decision gate could be placed in front of the send letter task to bypass the task if the letter has already been send. Note this does not disable the non-interrupting timer, it may still fire, its just that is does nothing.

timer to sent second dunning letter after fourteen days if first dunning letter already sent and payment not received

This is the reason I designed it to send the letter every time is because in your original model seemed to want that?

Yes as soon as the human task completes, then all associated boundary events are cancelled/removed.

regards

Rob

5