Human Task Manager - Changes & Fixes

This page covers changes and fixes to Human Task Manager provided in IPF Release 2025.3.0

New

TaskClosedNotifications and Processing Context

ProcessingContext was added to the schema of TaskClosedNotification as an optional processingContext field. It will always have the same value that was provided during task registration.

As part of the sweeping processing context changes, processing context from the notification will now be mapped to a new set of headers.

Processing Entity Support for Task Operations

HTM now supports processing entity isolation through an optional processingEntity parameter across all task operations. This enables multi-tenant scenarios where tasks belonging to different processing entities should be isolated from each other.

Task Query Operations

  • GET /tasks/{taskId} - Added optional processingEntity query parameter

  • GET /tasks/{taskId}/history - Added optional processingEntity query parameter

When processingEntity is provided: * Tasks are only returned if they belong to the specified processing entity or have processing entity "UNKNOWN" * Returns 404 (Not Found) if the task exists but belongs to a different processing entity * Preserves existing behavior when parameter is not provided

Task Command Operations

All task command operations now support an optional processingEntity parameter in the request body:

  • POST /tasks/{taskId}/assign - Assign task to operator

  • POST /tasks/{taskId}/execute - Execute task

  • POST /tasks/{taskId}/approve - Approve task

  • POST /tasks/{taskId}/reject - Reject task

  • POST /tasks/{taskId}/cancel - Cancel task

When processingEntity is provided: * Operations are only allowed if the request processing entity matches the task’s processing entity * Returns 400 (Bad Request) with descriptive error message if processing entities don’t match * Preserves existing behavior when parameter is not provided

Usage Examples

Query task with processing entity filtering:

GET /tasks/12345?processingEntity=BankA
GET /tasks/12345/history?processingEntity=BankA

Execute task with processing entity validation:

POST /tasks/12345/execute
{
  "operatorId": "operator1",
  "outcome": "approved",
  "processingEntity": "BankA"
}

Task Bulk Operations

  • POST /bulk-tasks/{bulkId} - Added an optional processingEntity parameter in the request body

  • GET /bulk-tasks/{bulkId} - Added an optional processingEntity query parameter

When processingEntity is provided in POST request: * Bulk execution is allowed if all tasks' processing entity match the processing entity in request * Returns 400 (Bad Request) with a descriptive error message if processing entities don’t match When processingEntity is not provided in POST request: * Preserves existing behaviour

When processingEntity is provided in GET request: * Bulk execution is allowed if tasks' processing entity has value UNKNOWN or match the processing entity in request * Returns 404 (Not Found) with a descriptive error message if the criteria above is not matched When processingEntity is not provided in GET request: * Preserves existing behaviour

Fixed

Filtering Task Closed Notifications based on source application name

human-task-manager-model

  • Added an optional field to RegisterTaskRequest to hold the name of the application registering a task with HTM

  • Added an optional field to TaskClosedNotification to include the targetAppName which represents the name of application that is intended to receive the notification.

human-task-manager

  • Added mappings to save the sourceAppName to TaskEntity

  • Added mappings to include the sourceAppName as targetAppName

human-task-manager-flo-client

  • Added a filter mechanism to DefaultHtmReceiver to match the receiving application name and the targetAppName