State which user has started a job on Orchestrator

Often times we have jobs that we manually start in Orchestrator but it would be useful to see which users have started the job so we can audit things better.

Currently the source states ‘manual’, but this is the same for when a job has been started by another process or if it’s been manually started through Orchestrator.

  1. Custom Logging: When a user manually starts a job, you can add custom logging within the job’s process. For example, you can use custom log messages at the beginning of the process to record the username or user ID who initiated the job. These log messages can include details like the timestamp and user information.

  2. Use Asset or Queue Item: You can create an Orchestrator Asset or Queue Item to store the user information before starting the job. The user initiating the job can update this asset or queue item with their information, and the job can access it during execution.

  3. Retrieve User Information: Within your automation process, you can include steps to retrieve the user information from the Orchestrator Asset or Queue Item created in step 2. This information can be logged or used as needed within the automation.

  4. Custom Reports: Develop custom reports or dashboards that access the logs and the custom user information. This way, you can generate audit reports that include details about which user initiated each job.

Hi thanks for your response!

All this is reasonable, however we’d prefer to not have to go into each job to know who initiated it, or rely on people to manually update queue items and assign themselves to those, and being able to see the user as one of the columns in the job interface in orchestrator would be much more beneficial, especially at a glance.

1 Like

As far as I know the actual user that initiated the job is not stored in the logs for the job nor available to the robot so all the suggestions above cannot work, for example the user manually starting a job, how is the robot supposed to determine who is was that did that in order to then log who is was in ‘Custom Logging’.

The information you seek is only really available via the Audit logs, specifically the logs for starting a job, however the details of the specific job such as the ID are buried in a serialized JSON object on a customdata field making it rather a chore to get to…

Whilst possible its quite some effort to look up this detail as a result.

From our perspective, having to go into the audit logs each time is a chore as you’ve said.

This is why, in my team, we think having an additional column added to Orchestrator could be beneficial

You, I absolutely agree, but for the reasons I explained I think it could be tricky to implement. I have an idea to help you but it would take some time so let me see if I get a chance since I have a few projects I want to experiment with.

1 Like