Get external task list - more filters, more result fields?

When we use the REST API call GET /task, we get a list of user tasks, and we can pass in a processDefinitionName as one of the filters. The results include a lot of useful information, including the task name of each task.

However, when we use the GET /external-task call to get a list of external tasks, we are unable to pass in the process definition name (we can, however, pass in the process definition id – so we’d need to make another API call to translate a process definition name into its corresponding id), and the results do not include the task name of each external task (however, we do get back the task id, and thus we’d need to make another API call FOR EACH RETURNED TASK to translate the task id into its name).

Is there a reason why GET /external-task is not as full-featured as GET /task, in terms of the input query parameters and the output results?

Hi @kilsen,

user tasks are made for humans and external-tasks are made for machines. And machines usually don’t care about names and process definitions :wink:

What is your use case to filter for process definitions on external-tasks?

And what do you want to do with the name of the task?

Cheers, Ingo

Hi; thanks for the response.

We’re showing a table on a supervisor’s page, with a list of all process instances for a particular process. For each process instance, we want to show the state that it’s in. For user tasks, we can conveniently get the “friendly” name of the task back when we get the list of all user tasks for the process. But for external tasks, all we get is the internal task id, and so we have to translate it to a “friendly” name for display purposes.

(And then there’s the other issue: when we request the list of external tasks, we can’t pass in the process definition name; we can only pass in the process definition id.)

Hi @kilsen,

when you use the history query ( you can filter for process names and display them.

But unfortunately the task name is not saved in the database yet:

Maybe you would like to contribute on this missing piece?

Cheers, Ingo