Open APIs

Hello,

I would like to report a clear inconsistency I've found in the documentation for the TMF701 Process Flow Management API regarding the "List task flows" operation.

There is a direct conflict between the defined endpoint path and the provided usage sample in the specification:

1. Defined Endpoint Path - hierarchical/nested structure: GET processFlow/{processFlowId}/taskFlow?fields=...&{filtering}

2. Usage Sample - "flat" structure where the processFlowId is used as a query parameter rather than a path parameter: GET /tmf-api/processFlowManagement/v4/taskFlow?fields=id,href,state&processFlowId=4fd-ty56-gg55

These two definitions are mutually exclusive. The first one treats taskFlow as a sub-resource, making the processFlowId mandatory in the URL path. The second one treats taskFlow as a top-level resource, making it possible to query tasks across different processes (or filter them by process ID).

This causes significant confusion. A nested path (option 1) restricts the API's utility, as it prevents fetching tasks in a global context (e.g., "all tasks assigned to a specific user" across all processes), whereas the sample (option 2) suggests a much more flexible design.

I am attaching a screenshot of the documentation for reference.

Best regards,

Hi Mikołaj, 

Thank you for raising this,

We completely agree with your observation. The current implementation assumed that tasks are subresources that cannot be identified outside the running process, which may be acceptable for some implementations but has limitations, as you described.

This has been addressed in v5, and we decided to keep TaskFlow as a standalone resource addressable directly by its id. v5 will be available soon in the Open API Directory.

Best Regards