Orchestrator - We reorganized the job details page

Hi!

Starting today, we made a change in Community Orchestrator to how the job information is displayed from the jobs grid.

Before, pressing the info icon was opening a popup with the job details. Now, we are opening a side panel.

This offers several benefits:

  • more real estate for information can be displayed; the panel can be resized to your requirements and it can also be expanded to a full-screen
  • you can move through different jobs by selecting the row and the job info will be displayed (without having to close and reopen a popup)
  • there is a second tab on the page where you can easily access the job logs
  • you can increase the size of the columns and the scroll will appear

You can find the release notes for more details:

We are curious to know what you think about this feature. Will it make it easier for you to view/troubleshoot the jobs page?

Thank you in advance for sharing your feedbac!

9 Likes

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.

2 Likes

Hi Kevin, good to know, thanks for letting us know. Is there anything else that would make your life easier when troubleshooting?

Hi @Corina_Marginas
that is a really good feature. I have one or two ideas for improving troubleshooting.

  1. 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.
    image

  2. 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.

  3. 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.

Thank you!

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.

1 Like

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.

Hi @PeCour ,

  1. 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.
  2. 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.
  3. I need more details about this issue. Can you post more specific reproduction steps or a video? Thanks.

Hi @Corina_Marginas,

thank you!

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.

1 Like

Nice update.
The life of the right click on my mouse has been greatly extended!

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.

1 Like

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)?

This is simply perfect :slight_smile: #userfriendly

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.

1 Like

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?

If yes, then “Reset to defaults” should release the filter and when it does it INTERVAL defaults to “Lastday” which is a menace.

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.

Good one. Gives value to support team.
Regards,
Balram

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.

Thanks!

I sent you a private message, please contact me directly to work through the feedback. Thanks!

1 Like