Unclaim user task AFTER certain time


I have a lot of ideas in my mind regarding this problem but I was hoping I could get a “best practice” one from you guys. I need to unclaim a user task after a certain period of time of being claimed by a user. What is the best approach for this?


No sure if it’s the most effective way, but you could add a boundary timer event to the User task and use execution listener to clear the task assignee.

EDIT: Just noticed you wanted it to be released after it has been claimed for a time. My solution would start the timer at creation of the task, so it might not work.

Actually you might use a task lister to set the due date on assignment and another on timeout to unclaim it.

When you mentioned timeout, you were referring to the due date timeout? If so, how can I catch the due date timeout?

I have not tested it my self, but in User Task properties, on Listener Tabs you can configure task listeners. One listener you can configure is ‘timeout’ which should fire when you hit the due date.

1 Like

Regarding the timeout, I must choose Date, Duration or Cycle in the type. So, it does not trigger by hitting the due date :confused:

Timer needs configuration (either timeDate, timeCycle or timeDuration is needed).

Well you could use duration, say “PT2H” for example if you would like to task to unclaim after 2 hours,

or you could set a date in a variable in another listener that is triggered on assignment and use that date in timeDate configuration.

I’ll try this out myself when I find the 15 mins to do it.

Yeah, expressions can be used for the timeout definition. Maybe even something like ${task.dueDate} works for the timeout listener. If the duedate changes, you could register an additional listener on update that updates the job’s due date via ManagementService#setJobDuedate. Haven’t tried this myself, so might have some pitfalls. But I’m confident this can be solved.

After some tests we ran into this:

  • The timeout listener does not know that the due date changed on assignment listener
  • If we try to manipulate the job due date via REST API we don’t know how we can get the job id of the timeout listener (in our example we have several jobs running right from the start)

Is there a way we can go around this? Can we get the job id “inside” the user task (e.g. on the update listener)?

We managed to update the job due date and unclaim the task. After that, the job finishes and for that reason we cannot unclaim it again since there’s no job. We still tried to start the job using the job definition (ManagementService#activateJobByJobDefinitionId) , but unsuccessfully.

1 Like

Did you get any solution for this?
We also have exactly same requirement. We want if a user has claimed a task and does not work on it for say 15 mins then it should automatically get unclaimed. The task should come back for getting claimed again.

Any help is much appreciated!!


We used this feature when running Activiti but after migrating to Camunda we couldn’t find the equivalent feature, and therfore we are using a nightly job to unclaim all claimed tasks.
Its not exactly what we wanted, but acceptable for our purpose.

What about defining a separate process that runs every 15 mins. Query for the tasks and check if they have been updated or not during last 15 mins? If a task has not been updated during that time, it could be released?

We ended up creating a small loop that would cancel the expirable task and create a new one.

Inside our user task, we created two listeners: assignment and timeout.

The idea behind this is that, once an user claims the task, the assignment listener is triggered and we would update an ENDLESSLY LARGE timeout (created in the beggining of the process) for the time we want as “claim timeout” for the timeout listener. This is needed because Camunda demands that a timeout listener has an assigned time.

In our case, 60 days is more than enough because this user task will be triggered earlier.

Once the user claims the task and the due date is reached, the timeout is triggered and will complete the task (without actually doing anything to it) and recreate the same task, this time with no one assigned to it. This is a viable solution for us since we do not make use of Camunda’s cockpit for the completion of tasks.

The assignment listener exists so that we can update the due date of the user task and the job behind it.

Assignment listener code:

var timeout = task.getVariable('characteriseTimeoutHours');

var expirationDate = new Date();
expirationDate.setSeconds(expirationDate.getSeconds() + timeout);

task.dueDate = new java.util.Date(expirationDate.toString());

//Clear timeout flag
task.setVariable('characteriseTimedout', false);

//Get time out job
var job = managementService

var timeout = task.getVariable('characteriseTimeoutHours');
var expirationDate = new Date();
expirationDate.setSeconds(expirationDate.getSeconds() + timeout);

//Update timeout to a new one
managementService.setJobDuedate(job.getId(), new java.util.Date(expirationDate.toString()));

Timeout listener code:

task.setVariable('characteriseTimedout', true);
1 Like


Update on the solution:

We’ve tested this solution on a local Camunda engine, on Spring Boot, but when we tried to run this on production environment (Kubernetes with official tomcat 7.14 camunda image), we had an error that “managementService” was not defined. Is there an environment variable any other configuration that would unlock the management service?