Camunda 8 Timer Event

Hi Team,
I have kind of validation, if my workflow not move any stage for 30 mints, I have to end the whole process (Kind of session).
But I have to expose one common message event action which should refresh my timer again as 30 mints. .
Eg: I am in the task1 and my timer is 30 mints… After 15 mints if customer hit one api, I want to refresh the timer again. So now without task1 completion. the time is over 15 mints, again my end timer should be 30 mints…

How can I handle this ?

@wvinothkumar You can try something like this.

  • Interrupting timer boundary event is used to exit the flow once 30 mins time is elapsed.
  • Non interrupting message boundary event is notify the zeebe engine that api call is made, so that it can reset the timer to 30 mins.

Hi @aravindhrs - Looks local variable is updating, but timer is not changing the initial period what we set

Hi @wvinothkumar

Kindly find attached a simple working example. The timer in the example is configured with 5 minutes as duration
(A unique requestId is required, which represents the unique identifier for each instance)



timer_test_c8.bpmn (12.9 KB)

Hi @wvinothkumar,

The proposed solution above assumes a 30-minute deadline for the entire process. However, it seems your requirement is to have a 30-minute deadline for each individual task. You can still apply a similar approach by wrapping each user task in an embedded sub-process and placing the same event sub-processes inside it.

Alternatively, you could use both an interrupting boundary timer event and a message event. If the message event is caught, the flow returns to the user task. This approach effectively resets the timer, but it results in a new task ID for the user task, which you’ll need to handle accordingly.

session-expired.bpmn (8.7 KB)

Camunda 8 Timer Event - Camunda 8 Topics - Camunda Forum

Slight different my diagram. Can you help me to understand in better way please.

When the task is not moved from one to another for 5 mints, my session expired time out should call. Same time when task move from Task 2 to Task 3, timer should reset back for 5 mints again.

One solution would be as follows (This approach effectively resets the timer, but it results in a new task ID for the user task, which you’ll need to handle accordingly)

Another solution would be as follows however, it increases the complexity of the model.