topic Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object. in Product Forum

WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

vipima — Wed, 22 Apr 2026 17:06:51 GMT

Hello All,

We are currently on BP 7.1.0 and soon will be moving to Next Gen/WorkHQ. Based on the documentation we saw that Get Report Data action is not available in Next Gen. Is that true? The reason for confusion is that in one of the training videos for Next Gen it was mentioned that Get Transaction Data is not available. Also in one of the training videos for Next Gen there was a screenshot of the Work Queue objects actions and it did show Get Report Data as an action. So I'm wondering if the screenshot is an old one which was reused in the training video and the Get Report Data method is indeed not available?

Thanks,

Vipin

Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

david.l.morris — Mon, 27 Apr 2026 13:23:27 GMT

I haven't used WorkHQ, but I saw this before when glancing over the documentation a while back.

This page does indicate that Get Report Data is not available in WorkHQ: Work Queues internal business object. The fact that the action is listed on that page is an indication that it is intended to be supported but that it simply hasn't been added yet. I would be shocked if it didn't get added at some point in the future.

Get Transaction Data is a different action that has been deprecated for many years.

As for the screenshot showing the Get Report Data action, I would assume that either it's an old screenshot like you said or it is that the action is listed in the VBO that is used for WorkHQ but that the action hasn't been made functional yet for WorkHQ.

Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

JayneT — Mon, 18 May 2026 09:53:24 GMT

Hi Vipin

In WorkHQ, Get Report Data isn’t implemented as a native Work Queue action. We have a course on Blue Prism University (Blue Prism® WorkHQ: Migrating to the Platform) which, in Section 7, indicates that this type of reporting can be constructed manually using:

Get Completed Items
Get Exception Items
Get Pending Items

This means that although the capability still exists, it’s no longer provided as a single out-of-the-box action in the same way as in Enterprise.

Can you share what you’re currently using Get Report Data for?

Thanks

Jayne - Blue Prism University

Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

david.l.morris — Wed, 27 May 2026 18:46:45 GMT

Hi @JayneT,

I'm surprised to hear that Blue Prism doesn't intend to implement Get Report Data. I have so many things to say about this lol, but I'll only mention the things off the top of my head and what is obvious to me when glancing at the internal business object Work Queues (Spoiler: This turned out to be a lot. I just can't help but be me.). Note that I did attempt to verify that the WorkHQ documentation that I linked to earlier shows the same inputs and outputs as v7.4.2 HF1 which is what I am using as a reference, and they look the same to me for the actions that exist in both.

There are 5 actions (not 3) that would be used to replace Get Report Data (one of which doesn't exist):
Get Pending Items
Get Locked Items
Get Completed Items
Get Exception Items
Get Deferred Items (does not exist -- see 2D below)

1 - Overall, the benefit of Get Report Data is a single action that can be called to get all items (at least the Item IDs) at once that are to be reported on. You're suggesting that in the move from the legacy product to the new product that it is reasonable to more than quadruple the number of actions used for the same operation and also have to append the collections to each other to get the full list before then looping over them or whatever next or have separate loops for each type of collection.

2 - Get Report Data has at least more functionality than the other actions, though some of the other actions do have functionality that Get Report Data does not. We make heavy use of both.

2A - Get Report Data supports filtering on either the Loaded DateTime or the Finished DateTime, whereas actions such as Get Completed Items only support filtering on the Finished DateTime. It is normal to want to report on queue items loaded within a given time period regardless of when they actually finished and vice versa. 100% necessary? Maybe not but there are thousands of developers who potentially have used this functionality and it seems easy to just continue supporting it rather than drop seemingly unnecessary functionality. I personally have used both.

2B - Get Report Data supports filtering by Resource Names whereas only Get Exception Items supports Resource Name, and at that it only supports a single Resource Name instead of allowing multiple like Get Report Data does.

2C - Get Report Data outputs Time Total, Least Time, Most Time, Median Time, Mean Time, and Item Count. Obviously Item Count is not a big deal, but that is a useful output as it reduces the number of stages needed to accomplish the goal. The rest are arguable for sure, but they are stats that people may or may not be relying on so why not continue supporting it to help with transitioning to the new product?

2D - Get Report Data supports returning Deferred Items, but there is no Get Deferred Items action, and Get Pending Items doesn't return Deferred Items. If there's some way you know of to accomplish this, I would like to know because I think that this is missing functionality and we currently have to use Get Report Data to check for Deferred Items, which isn't ideal but it works.

2E - Note that the "Treat each attempt separately?" input I completely agree with not needing as I believe that was legacy functionality anyway. I think technically it does affect the Item Count output as that will tell you the total number of attempts (if the input is set to True), but it's just weird to rely on that I think.

3 - The 4 actions (that exist) that can be used instead of Get Report Data are inconsistent. Maybe they're different in WorkHQ, but from what I see in v7.4.2 HF1, they have some inconsistencies, and I did glance at the WorkHQ docs for the object and it seems to be the same. I would be curious if these have been resolved in WorkHQ and if so then that would be great but also that means the docs are incorrect.

3A - Get Completed Items and Get Exception Items can filter by Date, but Get Pending Items and Get Locked Items cannot. For example, it would be good to be able to query for whether any items are pending that are older than some timeframe and ignore more recent ones.

3B - Get Completed Items, Get Exception Items, and Get Pending Items support Maximum Rows (though the names of the inputs are different: 'Maximum Rows' vs 'Maximum'). But Get Locked Items does not support Maximum Rows.

3C - Get Completed Items and Get Exception Items support Maximum Rows, but they do not support Skip, which I would think is necessary in order to do pagination. However, Get Pending Items does support Skip.

Some other thoughts/concerns:

1 - As far as I know, there is no quick way to retrieve the item data of a given set of queue items without looping over them all. It seems to me that it should be possible to do this all at once, given some Maximum Rows input to avoid an overload on memory. I think if you were to look at a normal reporting process that a given customer uses, you'd see how mind blowing it is how many steps are required to do this. The removal of Get Report Data makes that even more complicated.

2 - Mark Item As Exception -- According to the documentation, this still outputs New Item ID. I believe this falls under the same legacy functionality as "Treat Each Item Separately" where this used to output a new Item ID, but at some point in Blue Prism v5 or earlier it was changed so that new attempts (that are created when marking an item as an exception) use the same Item ID as the original. So, now it outputs nothing. If this is here for backwards compatibility to not break automations that reference the output, then it makes sense but I'm not sure how they even work if they are doing that. If that's the case, then Get Report Data should exist for backwards compatibility too. If it's not for backwards compatibility, then the output should have been removed in the move to WorkHQ/Next Gen.

Feel free to forward this on to anyone. I am planning to create a long list of issues that I see, and I'll try to include these points as well, but it may be a while before I finish compiling that, and it'd be good to address some of these things in WorkHQ as early as possible before too many customers adopt it and thus make it more difficult

Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

chris.strong — Fri, 29 May 2026 10:59:46 GMT

Hi Vipin and Dave,

Chris Strong here, Group Product Manager at SS&C Blue Prism. I lead on Digital Workers in WorkHQ, which covers our RPA capabilities including the new Work Queues implementation, and also on the migration path from Enterprise into WorkHQ. The call on Get Report Data is mine to own, and I want to give you the full picture of the thinking behind it.

Some context on how we approached this overall. When developing WorkHQ (formerly Next Gen) we made a deliberate, conscious choice to keep RPA process execution and the calling actions consistent with Blue Prism Enterprise. The aim is to reduce migration effort and let customers pick up the wider benefits of WorkHQ without rewriting their automations. Most actions are therefore the same.

Work Queues are no exception to that principle. The actions you call remain mostly consistent, with the current exclusion of Get Report Data. What's changed is server-side. The Work Queues implementation has been rewritten from the ground up to be multi-tenant, cloud native and scalable. Blue Prism Enterprise is mostly self-deployed against a customer's own SQL Server, which doesn't carry the same constraints. WorkHQ must perform at scale for thousands of customers concurrently, so anything we implement on the queue side has to be designed to work at that scale. That's the lens we apply when deciding what comes across as-is, what gets reshaped, and what waits.

The bigger point I want to make is that we did not dismiss reporting. Orchestration and reporting were foundational requirements when we designed the WorkHQ REST API. Full API documentation is available online: https://documentation.blueprism.com/workhq/en-us/rest-api/rest-api.htm. Specifically, Retrieve Work Queue Items is built for this:

GET https://{tenant-domain}/regions/{region}/api/rpa/rest/v1/work-queues/{work-queue-id}/items

It returns a collection of items in the specified work queue.

The intent is that customers can pull work queue item data periodically and feed it into the Enterprise IT reporting tool of their choice, which is where most reporting workloads belong long-term anyway. The API will keep expanding, and we'll keep prioritizing what makes that integration easier.

That doesn't make Get Report Data a closed question. Dave, the points you've raised about the replacement actions and the wider behavior around exception handling and pagination are exactly the kind of detailed feedback we need. I want to take those through properly with the team rather than respond to each off the cuff.

Commitments:

A review of Get Report Data and the points you've raised, factoring in this feedback. I'm genuinely open on whether the answer is reinstating a single action, hardening the replacements, extending the API, or some combination. Our engineers have already reviewed it, and I'll be transparent: it isn't a quick or simple change to incorporate.
Review and update the guidance within the migration framework (WorkHQ Self Service Migration Framework).
A reply back to this thread once we've worked through it.

One pattern worth flagging in the meantime. The Get Report Data calculation logic can be wrapped inside a VBO that calls the existing actions, possibly leveraging the API too, aggregates the result, giving you a single action call from your processes. That's the same pattern we used for the Work Queue Items export sample on the Digital Exchange: https://digitalexchange.blueprism.com/cardDetails?id=142099. It's a path the community or a customer's own team can take to ease migration today while the longer-term product decision plays out.

A note on the Migration Framework Jayne pointed to. It's built from the learnings of our global professional services team who are actively supporting customers moving to WorkHQ. It's evergreen. As we learn more, as the product evolves, and as feedback like this comes in, we keep that material current. Based on this thread, one update we can make is clearer guidance on Get Report Data migration, including when to use the in-product actions, when to use the REST API for bulk reporting, when a wrapper VBO might fit, and the trade-offs between them.

Dave, if you do compile that longer issues list, please send it my way. The earlier we see it, the more of it we can address before WorkHQ adoption scales.

Vipin, in the short term, you have a few options depending on the use case. For in-process reporting decisions inside an automation, Jayne's three-action workaround is the route. For periodic enterprise reporting, the REST API endpoint above is the more powerful option and is where we expect that workload to live long-term. If you can share what your current Get Report Data usage looks like, we can point you at the right pattern and prioritize the gaps that matter most for your migration.

Thanks for raising this in the open.

Chris Strong

Group Product Manager

SS&C Blue Prism

Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

david.l.morris — Fri, 29 May 2026 12:33:02 GMT

Hi @chris.strong,

Thanks for the reply. Your points make sense. I appreciate your looking into it, even if your final decision is to not implement Get Report Data.

I don't know if I remembered to say this in my original reply or not; I frequently realize I forget to say this up front: When I provide these kinds of excessive feedback, I know some features simply have to change, not be supported anymore, etc., and I and other RPA developers will always adjust regardless of what the changes are. My main concern is to look for alternative ways to accomplish the same thing, and as you and I mentioned there are workarounds for everything discussed in this thread so far (except for maybe Get Deferred Items). It just means extra stages in many cases or a reuseable VBO/process that wraps the functionality. That's what we did at Southern Company. We have an extremely complicated Reporting process built by @SzymonWitek that takes all kinds of inputs to report on any queue with various kinds of transformations on the data. I do think this kind of approach is what orgs should do anyway.

As far as the longer issues list, I'll try to remember to CC you on it as I've always appreciated your thoughts on things. The topic came up through discussions with Rob Nicklin, Pratik Rathod, and some of the developers at Blue Prism related to some early access testing topics, and they agreed to let me word-puke all over the screen with everything I can think of across BPE when I asked about that. It didn't really occur to me before, but that does make sense to also account for those points in WorkHQ (at least to consider, even if no need/plan to implement).

That Get Deferred Items functionality is the only true "problem" that I see from not having Get Report Data, and I think adding an action like that is (maybe?) trivial.

My brain can't stop bringing up possible issues. I'll just mention this here as a reminder for myself when I come gather these thoughts to include in my long list (not asking for feedback on it now). The move to WorkHQ also means (I assume) that customers will not be able to directly query the Blue Prism database. We do this quite a lot. Most individual automations don't query the Blue Prism database, but our reuse components (such as our logging object) query in because it's not possible, for example, to get the name of the current process and stuff like that without querying the database using the current session ID and doing some joins. We also query the DB directly for reporting purposes (like for monitoring the environments) such as to check on offline resources and other stuff. So, again as a reminder to my future self, I need to look over the WorkHQ REST API and even the Blue Prism REST API and see if some or all of what we do is already supported there.

Thanks,

Dave

Re: WorkHQ/Next Gen - Question about Get Report Data in Work Queues object.

greggoodrem — Fri, 29 May 2026 20:34:36 GMT

Dave says it all!

In short I was really surprised when I first started using Blue Prism that it didn't have a great way of displaying the data in the work queues for the programme managers in each organisation. My first employer was hoping every single release there would be a huge upgrade on the analytics section with better reporting for himself.

Also why on earth did nobody build a 'Get Deferred Items'?!

I ultimately found a way round not having the 'Get Deferred Items' by using the 'Get Report Data' but it was a pain in the backside and not perfect which disappoints me. So deprecating this function will have quite a few developers very upset.