This is good. Previously when a job failed I would always open a new tab for the logs and a new tab to view the recording. If I had multiple jobs that failed, it was difficult to manage all those tabs. This new side panel makes it easier to navigate between different log pages for different jobs.
Hi @Corina_Marginas
that is a really good feature. I have one or two ideas for improving troubleshooting.
When you have a team that is doing the debugging it would be great to mark entries in the as solved. But so that everyone in the team can see that it is solved. It would be even better if a person could assign oneself to an alert and therefore mark that the person is working on it.
It would be great to be able to select several jobs on the jobs page and then restart them alltogether. The problem we face is that if several jobs fail with input from UiPath Apps for example. One has to click one by one to restart. It is difficult to keep the line since all entries look the same at the moment. Only the timestamp differs.
Sometimes after filtering the job page it doesn’t go back to normal and the job that is waiting is not displayed anymore at the top. I think that this happens, when we sort by “started” or “ended”. Then it is difficult to go back without closing the browser session.
For “Could not find the user-interface (UI) element for this action” errors: in Orchestrator logs it would be nice to include what targeting methods & selectors were used, which ones worked or failed, and the closest matches found.
In Studio it would be nice to have an activity similar to “Retry Scope”, where instead of retrying all activities in the scope, it only retries the single activity that failed. Often times we want to retry some activities but not all, so the current Retry Scope and Global Error Handler are not suitable.
Also in Studio, for “UI Element no longer valid”, have an option to try to search for the element again. Often the element has just disappeared and reappeared, for instance due to a screen reloading.
Also in Studio, for “Target element is disable”, have an option to wait until it is enabled. Often a target is only temporarily disabled, for instance due to a screen reloading.
I will say the Orchestrator debugging capabilities are far better than they were in 2020, and far better than competitors, and this is a big differentiator. The biggest improvements by far have been the ability to see in the logs which specific activity caused an error, and recordings.
Thanks @KevinE . These are all Studio requests so I will ask my collegues to log those into the Studio project to be taken into consideration in later releases.
Is a requirement for the new Notification changes we are making. I will send the request to the responsible team and they may take it into consideration for later releases.
The challenge I see is that on restart, one can update a lot of the job’s parameters. So a bulk sequence would be complicated from a UX perspective.
I need more details about this issue. Can you post more specific reproduction steps or a video? Thanks.
Regarding 2.: Maybe it would be possible to keep the same parameters / default parameters and skip the job’s parameters. But otherwise, I agree. It will be difficult. I did not think about it.
Regarding 3.: It is hard to reproduce but once I do, I will post a video.
It would be beneficial to see who submitted a job. Currently that information is not available directly.
environment.username only shows the AD account that is executing the job (which would typically be a service account). If the AD user account that started the job is made available, that would be awesome.
Example scenario where this will be crucial:
When an automation that any of 50+ buyers can potentially run completes, currently we have to manipulate the audit logs to determine who started the job to notify him/her on completion.
Hi @csathys thanks for the reply!
In your scenario, how do users start the job? Is it manual from the interface? Manual through the API? Is it through a trigger (and if yes, would you like to see the trigger as the source OR the name of the person who created the trigger)?
They would be logging into Orchestrator and into their folder to start the job. Adding the trigger source would be awesome as well. In fact, any audit information about the jobs run, process defined, would be great.
Additionally, ability to add a drop down list of values to parameters will be great way to control and validate inputs.
on your #3, when you say “filtering job”, I’m assuming you are referring to the “Job Status” in the folder’s HOME page, which filters jobs based on STATUS you clicked?
Yes, that is somewhat what I meant. But it gives me an idea.
When applying sorting e.g., sorting by time started, it would be great to also have the opportunity to “reset to defaults”. Otherwise, it is difficult to turn back to the default.
The problem is that the job, which is not yet running and therefore not started yet but is on the waitlist, is not displayed since we sorted started time ascending or descending.
Hi @Corina_Marginas,
some feedback since the feature is now available for us. The loading of the protocols does not work so well. It loads really long.
And it would be nice to see only the protocols of the selected process. For now one sees all protocols of the folder.
→ Edit: Sometimes the filter works, sometimes not.
