I have an inquiry regarding making a subtask via REST API.
I understand that by making a POST request to /flowable-rest/process-api/runtime/tasks creates a task, and by adding a parentTaskId, this makes a subtask. My issue that I am facing right now is that I want to also include my processInstanceId to link my subtask to my process, but this does not seem to be working. When I have searched online it seems that by making a subtask via REST API causes flowable to create a standalone task that is unlinked to the process, but is linked to the parent task only. I have also tried updating the subtask information with the processInstanceId via PUT requst to /flowable-rest/process-api/runtime/tasks/{taskId}, but this is also refused by flowable and the field remains null.
Does anyone know of a solution so that I am able to link my manually created subtasks to an active running process?
You cannot create a sub task linked to a process instance. You’ll need to use modeling with a User Task to have user tasks that are linked to a process.
What is your use case? Why do you need to add tasks dynamically to the process?
Thank you for the quick response @filiphr,
So my flowable engine is running in a docker image, I hit the docker image via REST API calls.
My frontend is in another docker image using angular framework.
In my UI I have a task list component that displays all current running user tasks, and in this task list I have the ability to create subtasks for any given task.
I wanted to link the subtask to the process so that I can do few things that seem to be blocked since the subtask is not a part of the process, such as pulling up all historical tasks for a process instance and closing subtasks with an outcome reason. I understand that I can pull up historical tasks using the parentTaskId, but I am trying to avoid having to make more request than necessary.
I do not want to “delete” the task, since I understand there is a deleteReason that I can use, but I want to correctly close the task using the POST request onto /flowable-rest/process-api/runtime/tasks/{taskId} with this in the body: { "action": "complete", "outcome": "accepted/rejected", }
But as of now, the outcome reason does not seem to be sticking to my subtasks, and my best guess as to why that is, is because there is no process instance connected to my manually created subtasks.
My best path forward as of now is to create a variable within the subtask, before closing it so that I can historically retrieve the task with its variables, and save the “close reason” within a variable. However this would result in more rest api requests.
If you have a better solution, it would be much apricated, or an explanation as to how/why I can not link subtasks to my process instance.
Main Task Creation: A customer submits a complex issue, and a new process instance is created in Flowable. This leads to the creation of a main task titled “Investigate Customer Issue #12345.” The main task is assigned to a senior customer service representative, Sarah.
Subtask Creation: As Sarah begins her investigation, she realizes the issue involves a bug in the billing system, which she can’t resolve herself. To get help, she creates a subtask titled “Analyze Billing System Logs for #12345” and assigns it to a technical support specialist, Tom.
Parallel Work:
Sarah (Main Task): Sarah continues to communicate with the customer, gathers more information, and documents the overall situation. Her main task remains active.
Tom (Subtask): Tom receives the subtask. He accesses the billing system, pulls the relevant logs, and analyzes them.
Subtask Completion: Tom finishes his analysis and completes the subtask. When completing the subtask, he includes a completion outcome of “Completed” and adds notes like “Found an error code related to a recent patch; provided the logs to Sarah.” These notes and the outcome are stored as task variables on the completed subtask.
Main Task Follow-up: Sarah, who is still working on the main task, now has access to the completed subtask’s information. She can retrieve Tom’s notes and the log files he provided. Based on this, she can now go back to the customer with a clear explanation and a path to a solution, and then complete her own main task.
for me it sounds like you are describing a CMMN case. There you can easily have user event listener or manual activation which you can invoke through the REST API to create a sub-task of the overall case. The information would then be available through the task API.
You can provide generic information then from Sarah and even trigger a process etc. to figure out who the task needs to be assigned to.
The main issue I am facing is that ad-hoc subtasks that are created, are not getting linked to the process instance.
Here are some more examples of use cases. I feel as though using CMMN would add complexity to my system, where I have not needed it as of yet.
A knowledge worker, such as a loan officer, receives a task to approve a loan. The process is a BPMN workflow that automates the standard steps, but the loan officer, with their expertise, identifies an issue with a specific document that requires clarification from a colleague in a different department. This is not an automated routing decision; it’s a judgment call based on the loan officer’s knowledge. They need to quickly create an ad-hoc subtask—“Clarify terms of the collateral agreement”—and assign it to their colleague. This subtask is critical to the main loan approval process, and the loan officer will pause their work while they wait for it to be completed.
Consider another use case: a healthcare professional is managing a patient’s treatment plan, which is a BPMN process with a series of scheduled tasks. Unexpected issues often arise that the automated process can’t account for. For example, a patient’s insurance information might need validation, or a specific medication requires a peer’s review for a potential interaction. The professional’s knowledge and expertise are essential to determine who to subtask these issues to. They need to create a subtask on the fly and assign it to the appropriate person without disrupting the main treatment plan workflow. The subtask must be linked to the parent patient record process instance so that a complete historical record can be retrieved later for auditing or compliance purposes.
In both of these scenarios, using CMMN would be overly complex. It would require the overhead of creating and managing a separate case model for what is essentially a single, spontaneous request for assistance. This approach is not about a flexible, long-running “case,” but about a single, dynamic action within a structured BPMN workflow. The current method of manually creating standalone subtasks and then searching for them in the history table is not performant for audit logs, as it requires multiple, inefficient queries. The ideal solution would be for Flowable to allow these dynamically created subtasks to be linked directly to the parent process instance. This would ensure a complete and easily retrievable audit trail, allowing a single query to show all related tasks, including the subtasks, for a given process.
Flowable Guru’s, I concur with Evan’s request. Ill give another example: an underwriter in an insurance company.
A customer applies for a new insurance policy. This triggers a standard, automated BPMN process to gather initial information and run basic checks. However, when the task lands on the underwriter’s desk, their specialized knowledge comes into play. They might notice a nuance in the applicant’s history or a detail in the property survey that doesn’t fit the automated model. Yeah, yeah, LLMs and all that may assist the user in discovering issues - but that is a different discussion.
Instead of pausing the entire process and re-routing it, the underwriter uses their expertise to create an adhoc subtask. For example, they might create a task titled “Obtain additional details on applicant’s previous claims” and assign it directly to a claims specialist. The underwriter’s judgment is what determines the need for the subtask and who is best suited to handle it. This isn’t a pre-defined step in the main workflow; it’s a dynamic, on-the-spot decision where the workflow drives the process, but the knowledge workers team with the process and provide that human insight to keep it running smoothly.
Using a full CMMN model for this would be overkill. It’s a single, targeted action that needs to be tied to the main policy application process for a complete audit trail and to ensure the underwriter can track its completion. The ability to create this subtask, link it to the main process instance, and then retrieve its history alongside all other tasks is crucial for the underwriter to have a comprehensive view of the policy’s journey. It allows them to maintain the efficiency of the BPMN workflow while leveraging their human expertise to address unique situations. Just allowing the REST API to accept the process instance ID so that the task can be tied back to the overall process is all that is asked. Thanks!
