Orchestrator: View Transaction at one click + Why is top menu dissapearing? + other ideas

Hello UiPath team! @uipath

My next set of suggestions for improvements

View Transaction at one click

I think that we all would appreciate if goint to the most obvious option in the Queue menu - View Transactions would be accessible by one click, ideally at the name of the Queue .


Also I don’t understand this behavior, when you View Transaction of a Queue, the top menu disappears

Idea: Create connection between Jobs and Queue Items

What would be also super cool would be if each “Job” can have some incremental counter, and in Queue it would be visible at what job was each transaction connected.
Some other solution of a classic problem: To display logs that are related only to one specific transaction. That would be so cool!!! :dark_sunglasses: :slight_smile:

Searching in logs is btw also not working much as expected. I would expect if searching for something in " " quotes it would search for literal text. But if I type in two words in brackets, it is just returning non-logical things.

+ impossible to read longer trigger details

Just – how?

+ it would be cool in list of Jobs see then amount of processed transactions

OR to have possibility, within a Job set some kind of status. So if for example the job ends with “no transaction data” it will be clearly visible in the Jobs section. :slight_smile: Or any other optional status.

I am really looking forward to some improvements at logs and around. That would ease the debugging so much! :heart:

Thank you!

1 Like

When an automation has gotten a transaction it sets the status to In Process. That’s how you know an item is being processed.

Logs per transaction don’t really make sense as a UiPath feature. Orchestrator etc don’t know what your automation is doing, the item is just a Queue Item variable. You could do this yourself by including something about the transaction in your Log Message activities…like:

“[” + transactionItem.SpecificContent(“SomeKey”).ToString + “] other log info here”

Then you could filter the log entries in Orchestrator based on the [value]

I agree that the search needs improvement. Especially when searching queue items, it doesn’t actually search the contents of the items (SpecificContent), just the properties of the items. So say your queue items have a key of Account Number and you want to search your Queue for a specific account number…you can’t.

I actually believe it makes a lot of sense. It is my daily bread. Robot processes lets say 20 transactions and few of them are not working as expected (say they fail or the result is wrong). First thing I will go and check the logs. If the process is long and complexx, there are 80 lines of log messages per transaction. To find log messages to each bad transaction I have to check the start time when it started processing and then go to Logs and go page by page searching for where it starts. This is already a very tiring moment where I think: Why on earth can’t we have better filtering based on time (not just Last Hour/Day/Week/30 days).

And that is where it can be quite easily solved! By the same way I do manually (in automation software in 2022). It knows time when transaction started and also when it ended.

So imagine a button by each Transaction Item like Show logs that would forward you to general Logs with set of timestamp based on the transaction started and ended.
Then, of course, if you have more robots running the same time, you would need to specify (filter) by host name.


It may be challenging, but I believe this could really help in debugging.
:wink: :wink: :wink: :wink:

I didn’t mean it doesn’t make sense as something you need to do. It doesn’t make sense as a built-in feature of Orchestrator because it doesn’t know which Log rows pertain to which transaction. As I explained, you can do it yourself.

Yes it knows when the transaction started and ended, based on your automation telling it - just like your automation needs to tell it which log entries are for which transaction, as I explained.