React on Task Lifecycle events to unblock Human Task Orchestration use cases
User Problem 🤦
Working with user tasks produces multiple lifecycle events, where each of them might be important to react to. With the current solution, customers need to consume lifecycle events (available only in Self-Managed) in their systems and react to events in a specific way. This is a problem as to satisfy this need customers have to provide additional infrastructure (to consume and store events), filter Zeebe events and react to specific ones. This approach might work only in self-managed installations with a custom Tasklist application.
The lack of this functionality prevents satisfying some HTO use cases where customers need to react to lifecycle events.
Example use cases:
Implementing complex user task assignment/reassignment logic using code
Check if a person can make a specific change
Validate assignments and user task actions
Notify user with a correct url of the user task that it's assigned to him;
React on cancellation of the user task with a notification
Release notes
The latest release enhances task lifecycle management, enabling users to react more effectively to various task lifecycle events with Task Listeners.
Now, process designers can effortlessly model task listeners for different events like assign, claim, or update. Developers can use the same job infrastructure to activate and complete task listener jobs.
User Stories 🧑🚀
Modeling:
As a Process Designer, I can model User Task Listeners (TL) on User Task type flownodes
As a Process Designer, I can define TLs for different lifecycle event types (assign, reassign, cancel etc.)
As a Process Designer, I can define a job (listener) definition type - to subscribe to as a worker
As a Process Designer, I can define the same properties as for the “usual” job (retires, etc.)
Execution:
As a Developer, I can use existing job worker API to work on taskListenerJobs. I can pass additional variables when completing a listener job
As a Developer, I can make use of the same Incident mechanism for TLs - when TL job fails and no retries left, an incident is created
As a Developer, I can get information about Incidents on TL
Value Proposition Statement 🚀
React on Task Lifecycle events to unblock Human Task Orchestration use cases
User Problem 🤦
Working with user tasks produces multiple lifecycle events, where each of them might be important to react to. With the current solution, customers need to consume lifecycle events (available only in Self-Managed) in their systems and react to events in a specific way. This is a problem as to satisfy this need customers have to provide additional infrastructure (to consume and store events), filter Zeebe events and react to specific ones. This approach might work only in self-managed installations with a custom Tasklist application.
The lack of this functionality prevents satisfying some HTO use cases where customers need to react to lifecycle events.
Example use cases:
Release notes
The latest release enhances task lifecycle management, enabling users to react more effectively to various task lifecycle events with Task Listeners. Now, process designers can effortlessly model task listeners for different events like assign, claim, or update. Developers can use the same job infrastructure to activate and complete task listener jobs.
User Stories 🧑🚀
Modeling:
As a Process Designer, I can model User Task Listeners (TL) on User Task type flownodes As a Process Designer, I can define TLs for different lifecycle event types (assign, reassign, cancel etc.) As a Process Designer, I can define a job (listener) definition type - to subscribe to as a worker As a Process Designer, I can define the same properties as for the “usual” job (retires, etc.)
Execution:
Implementation 👷
Infrastructure provided with https://github.com/camunda/product-hub/issues/1932
In scope:
Technical breakdown:
This iteration is dependent on iterations:
:robot: This issue is automatically synced from: source