Hi
thanks for your feedback so far.

The current Agent UI for workitems does not fully meet the requirements of our business because we work in Pull Mode only. We discussed our open points with Genesys product management and some points are strategic and will be published in the future, others are not strategic. We wonder if it is possible to develop an Agent UI which satisfies our needs as it was possible in Engage.
Here are some of our requirements:

• Generally, visible WI information (columns and filters) should not be self-manageable by agents, but rather be administrated by supervisors, or it is restricted right from the start based on agent's skills/teams/branches.
• More flexibility in visible WI information than with current GC UI: ability to include custom attributes in columns and filters.
• Agent viewable number of WIs depending on specific filters (up to 500 WIs expected).
• ...

WB_Team - Have you had any conversations with our Pre-Sales team about your use cases?

The way you did things in Engage may need to be approached in a different way in Genesys Cloud. What is your use case for needing to retrieve the 20K workitems? If you can let us know the end goal that you are trying to achieve then we can better advise you on an approach to use in Genesys Cloud.

Hi
We are looking into replacing our Genesys Engage environment with Genesys Cloud taskmanagement.
In our current solution, we process about 20'000 workitems per day, with the requirement that single endusers are able to view about 500 workitems (from private or shared work).

So, how could we efficiently retrieve a complete list of workitems in GC taskmanagement?
We tested "/api/v2/taskmanagement/workitems/query/jobs", which implements an async approach which looks inefficient, requiring one query job per page retrieved (max. page size of 200 workitems).

Is the workitems list view from the Genesys Cloud UI using the same approach (per user per request per page one async workitems query job)?

Jobs from "/api/v2/taskmanagement/workitems/query/jobs" are not manageable.
You need to catch the job id right at job creation, to async retrieve job results, and there is no API available to drop those query jobs.
Any problem from this, i.e. will GC manage job cleanups by itself?

Thanks a lot for your advice and have a nice day.