Dispatcher - reporting standards

Hi all, wanted to spark a bit of debate here to decide on pros and cons for dispatcher reporting.

As many organizations we have standardized reporting for our performers and we point our business users to the standardized dashboard to get insights into the different Business exceptions they need to handle: the report is based on queue items.

Now before something is a queue item and can be reported upon we often make use of a dispatcher to create a queue item. Within the dispatcher we can often find business logic (for example; only make a queue item for this & that item or if item fulfills condition X). Considering there is business logic there that means there can also be business exceptions (“no queue item created for item X because of dotdot, please process manually.”).

Since there is no queue item for this item this also falls outside the scope of the performer dashboards. How do you handle reporting these items not picked up by the dispatcher to the business? Do you point business to two different dashboards? Do you create a separate report in excel or something to demonstrate which items have been picked up and which haven’t?

I’d like to avoid some items getting stuck in the work repository of a bot just because the business doesen’t realise an item should be manually picked up.

Curious how people are handling this in their dispatchers in the rest of the world. Please share your insights and ideas!

@Robolution

Instead of doing that in dispatcher…we can add everything to wueue and do these logics in performer only

or

after the logics in dispatcher …add a queue item
In case of business exception as well and in performer first check if busienss exception is present …which is propagated from dispatcher and throw a exception which can be added to same report

This is something we follow not to have two reports and maintain everything in one

Hope this helps

Cheers

I also prefer not to do much business logics in the dispatcher… But if you need to have a report of dispatcher actions, one thing you could do is use a common report output location - file, Orchestrator queue, database, … That way you can write messages from both Dispatcher/ Performer and have just one report.