Hey @Monika, following are some of the automation best practices that can be used in UiPath Orchestrator:
- Multi-Tenancy: Orchestrator offers a multi-tenancy option. By using more than one tenant, users can split a single instance of Orchestrator into multiple environments, each with its own Robots, processes, logs and so on. This can be very useful when separated artifacts for different departments or different instances for clients are needed.
-
Robots: Use meaningful names and descriptions for each provisioned Robot. The next step after registering the Robot to Orchestrator is to check if its status is Available, in the Robots page. For Unattended Robots, the Windows credentials are needed in order to run unattended jobs on them while Attended Robots don't need credentials because the jobs are triggered manually by human agents, directly on the machine where the Robots are installed.
-
Processes: Old versions of processes should be deleted from time to time, that are not used anymore. Versions can be deleted one-by-one, by selecting them manually and clicking the Delete button or the Delete Inactive button. The latter deletes all the process versions that are not used by any process. It’s recommended to keep at least one old version to be able to rollback if something is wrong with the latest process version.
-
Logs: The Add Log Fields activity adds more arguments to Robot logs for a better management. After using it in the workflow, the Log Message activity also logs the previously added fields.
-
Transactions: The Add Transaction Item activity brings the option of getting all the Transactions functionalities without using a queue, but one should still be created before. This activity adds an item to the queue and sets its status to InProgress. Start using the item right away and don’t forget to use the Set Transaction Status activity at the end of your process.
-
Queues: Use a meaningful name and description for each queue created. At the end of the life cycle of each transaction, it is mandatory to set the result of the item processing. Otherwise, transactions that have the New status are automatically transitioned to Abandoned after 24 hours. Using the Set Transaction Status activity, a queue item's status can be set to Successful or Failed. Keep in mind that only the Failed items with Application ErrorType are going to be retried if configured.
-
Environments: Orchestrator Environments should map the groups of process execution. If a Robot is going to execute two different roles, it can be assigned to multiple environments. If you have multiple Robots on the same machine, it is recommended that you group them in the same environment. Access management between Robots and processes is done by using Environments properly.
-
Jobs: If the Robot needs to run multiple processes with no interruption, all the jobs should be triggered one after another even if the Robot is busy. These jobs go in a queue, with the Pending status, and when the Robot is available again, Orchestrator triggers the next job. To be able to stop a job, the Should Stop activity is needed in the process workflow. The Kill button sends a Kill command to the Robot. This should be used only when needed, because the Robot might be right in the middle of an action.
