Settings

The Settings page enables administrators to adjust Orchestrator tenant settings.

General Tab

Field	Description
Application Settings	Time Zone - The time zone of the tenant. By default, this field is set to UTC. Interaction configuration - Includes the Strong confirmation on delete option, which allows you to determine how strictly to treat the deletion of Orchestrator objects. If selected, a confirmation window is displayed, asking you to type a text before carrying out the deletion. Display settings - Includes the High density view option, which is selected by default. Deselecting it allows you to switch to a low-density display of table items. This applies to the entire tenant.
Personal Workspaces	Automatically configure Serverless machines in Personal Workspace for Studio Web users - Option selected by default, allowing Serverless machines to be automatically provisioned in the personal workspaces of users who design or debug in Studio Web. Deselecting the option prevents Serverless machines from being automatically created in personal workspaces, which may impact designing or debugging processes in Studio Web. Note: Deselecting the option does not deallocate the Serverless machine from your personal workspace. Explicit deallocation of the Serverless machine might be required. Automatically stop exploring Personal Workspaces after - Allows Orchestrator administrators to enforce a rule dictating that personal workspace exploration is automatically stopped after a set amount of time. The available options are 15 minutes,1 hour,1 day, and custom value. By default, when migrating or creating new tenants, this value is not set. You need to configure it manually once the migration/creation process is completed. Stop all active sessions for exploring Personal Workspaces - Allows Orchestrator administrators to stop all currently active personal workspace exploration sessions. This is suffixed by the number of active sessions, displayed in parentheses, and can be enabled by clicking Stop session(s) explore. Changes you make to exploration settings do not apply retroactively to sessions that have already been explored. Mass enable Personal workspaces for current users and groups: - Create personal workspaces for all users in a tenant that use a certain attended licensing profile, while also selecting the UI profile to be used for those users. This action cannot be reversed, once the Personal Workspaces feature is enabled it cannot be disabled.
Standard Roles	Create standard roles for folders. These roles allow you to leverage the benefits of user groups. Click Create Role next to each of the roles you want create.
Client Binaries (Robot, Studio, Assistant) Auto-Update Settings	Ignore auto-update status for robot machines that were offline for more than ___ days - Exclude inactive machines from the update process and no longer take them into account when the update status is reported.
Folders	Enable account-machine mappings - Enable the Account-Machine Mappings feature.

Execution Settings section

Field / Default value	Description
Triggers - Jobs count strategy (Triggers.JobsCountStrategy) Default value: Per Process	Choose the job count strategy for jobs launched through triggers. Note that this doesn't take into account any arguments that may have been provided. The following options are available: Per Process - A trigger launches the required number of jobs taking into account any pending jobs for the specified process. For example, two triggers defined for the same process launch 3 and 5 jobs, respectively. If the first trigger launches 3 jobs at a given point in time, when the second trigger is set off, 2 jobs are launched so as to reach the 5 required jobs. Per Trigger - A trigger launches the required number of jobs taking into account any existing jobs previously launched by that same trigger. For example, a trigger is defined to launch 5 jobs at a given point in time. If 3 jobs have been successfully completed by the time this trigger is set off again, Orchestrator launches another 2 jobs so as to reach the 5 required jobs.
Triggers - Queue triggers - Enable pending jobs strategy (Features.QueueTriggers.PendingJobsStrategy) Default value: True	Choose the computation method for the number of additional jobs to be triggered when new items are added to a queue. This is done by subtracting the number of jobs in a certain state from the maximum targeted number of jobs to be created. The following options are available: True - This option is best suited for cases where you want Orchestrator to assume that all running jobs have already moved queue items out of the status New. The number is computed as follows: Maximum additional jobs to be created based on newly available queue items = the maximum number of pending and running jobs allowed simultaneously minus the number of jobs in a Pending state. False - This option is best suited for cases where you want Orchestrator to assume all running jobs have yet to move queue items out of the status New. The number is computed as follows: Maximum additional jobs to be created based on newly available queue items = the maximum number of pending and running jobs allowed simultaneously minus the number of jobs in one of these states: Pending,Resumed,Running,Stopping,Terminating.
Triggers - Disable when job creation fail count (Triggers.DisableWhenFailedCount) Default value: 10	Configure a trigger to get disabled automatically after a certain number of failed launches and no successful runs occurring in a specific number of days. This option works in conjunction with Triggers -Grace period when job creation keeps failing count (days), as follows: Triggers - Disable when job creation fail count allows you to adjust the number of failed runs, whereas Triggers - Disable when it keeps failing count (days) enables you to change the number of days. By default, the Triggers - Disable when job creation fail count value is 10, and the Triggers - Grace period when job creation keeps failing count (days) value is 1, which means that the trigger is disabled after 10 unsuccessful attempts to launch if there were no successful runs in the past day. This option can be set within a range from 10 to 100.
Triggers - Grace period when job creation keeps failing count (days) (Triggers.DisableWhenFailingSinceDays) Default value: 1	Configure a trigger to get disabled automatically after a certain number of failed launches and no successful runs occurring in a specific number of days. This option works in conjunction with Triggers - Disable when failed count, as detailed above. It can be set within a range from 1 to 30.
Triggers - Connected triggers - Disable when job execution fail count Default value: 5	Note: This only targets connected triggers (i.e. triggers created in Studio Web) published to personal workspaces. The trigger is disabled after the number of failed executions you choose for this setting. It can be set within a range from 0 to 100, where 0 means that the trigger is never disabled. If you select 0, Triggers - Connected triggers - Grace period when job execution keeps failing count (days) becomes irrelevant, and its field is disabled. This setting is only valid for newly created connected triggers. Changes are not applied retroactively to existing connected triggers.
Triggers - Connected triggers - Grace period when job execution keeps failing count (days) Default value: 0	Note: This only targets connected triggers (i.e. triggers created in Studio Web) published to personal workspaces. This settings dictates the number of days to wait before the trigger is disabled after the first failure of a job. It can be set within a range from 0 to 30. If Triggers - Connected triggers - Disable when job execution fail count is 0, this field is disabled.
Triggers - API Triggers - Maximum pending jobs limit Default value: 10	Set the maximum number of pending jobs that can be created by an API trigger. The supported range is 1 - 100.
Queues - Abandon in progress queue items after threshold (hours) (inProgressMaxNumberOfMinutes) Default value: 24	Set the maximum amount of time, in hours, that queue items can have the In Progress status. After this time, the status of the queue items changes to Abandoned. The default value is 24 hours, which means that queue items cannot be marked as Abandoned unless they have had the In Progress status for at least one day. This is handled by a background job which runs once every hour. Hence, you can expect the transition to happen up to one hour after the selected value.
Queues - Unprocessed queue items check frequency (minutes) (Queue.ProcessActivationSchedule) Default value: 30	The amount of time between checks for unprocessed queue items. To adjust the check interval, you can choose between 10, 15, 20, 30, or 60 minutes. For every queue trigger you create, we generate a background time trigger that is meant to handle queue items which could not be processed at the very moment that they were enqueued. This background time trigger is used to compute the frequency dictated by the setting. Existing queue triggers: the setting is applied when the default value is changed for the first time, and cannot be restored. New queue triggers: the setting is always applied. Important: The reference timestamp used is based on the time that the queue trigger was created. For instance, if a queue trigger is created at 14:22:43, and this option is set to 10 minutes, the following recurrence is generated: 14:32:43, 14:42:43, 14:52:43, and so on. The background task that performs the changes triggered by this setting can take up to 10 minutes to come into effect.
Jobs - Terminating timeout (hours) (Jobs.TerminatingJobsTimeout) Default value: 24	Set the time elapsed, in hours, until Terminating jobs become fit to be marked as Failed. The default value is 24, which means that jobs cannot be marked as Failed unless they have been in a Terminating state for at least one day. This is handled by a background job which runs once every hour. Hence, you can expect the transition to happen up to one hour after the selected value.

API Settings section

Setting	Description
CORS allow list for API triggers	Allows you to enter domains permitted for incoming traffic. Separate distinct domains through a comma or by pressing Enter.
Require Authentication header for sync API Triggers redirects	This is enabled by default, and it enforces the use of an authentication header when selecting the Sync (long-polling) call mode for an API trigger.
Strict API	If enabled, certain API fields become non-filterable and/or non-sortable, thus helping prevent performance issues. You can see a list of these fields in the dedicated page. This setting is enabled by default for new tenants, but existing tenants need to be opted in manually. Keeping this option enabled at all times is a recommended best practice in API integrations.

Deployment Tab

Enables you to configure and secure feeds for packages and libraries. You can manage the feeds for all tenants from a centralized location using Automation Ops. For more information, see feeds management in the Automation Ops guide.

Settings here only affect tenant feeds; folder feeds and personal workspace feeds are always internal and available in the context of the respective folder or personal workspace alone.

Packages

Enables you to set an internal or an external feed in which automation packages can be maintained. By default, an internal feed is used. The feeds can be secured either by defining basic authentication credentials or by using an API key.

Field	Description
Internal	Use an internal feed. The feed can be secured either with the Secure Deployment option or by using an API key: Secure Deployment - Ensures that your automation packages are downloaded through a secure NuGet feed. API Key - The key used to secure your feed against write operations such as delete or upload. This is only required if you want to upload a package directly to the NuGet feed using an external client.
External	Use an external feed. The feed can be secured either by using an API key or basic authentication credentials: Deployment URL * - The address where the NuGet feed is located. API Key - The key used to secure your feed against write operations such as delete or upload. Authentication - Enables you to specify the credentials for your basic authenticated feed. Please keep in mind that both the username and the password used with the API Key option should be used in this case as well.

Important: We do not support cross-platform packages uploaded to an external feed. Their metadata can only be read if they are uploaded directly to Orchestrator.

Libraries

Enables you to configure the feed to be used for library and activity packages.

Field	Description
Only host feed	Libraries are stored in the host feed and are available to all tenants which use it. The Libraries page is the same for one Orchestrator instance, meaning libraries are not isolated at the tenant level: each tenant has access to the other tenants' activity. You cannot upload libraries from Orchestrator if this option is selected. This option gives robot access to the host feed only.
Only tenant feed	Libraries are isolated at the tenant level, meaning data is separated across tenants. You may set an internal or an external feed in which libraries are maintained. By default, an internal feed is used. This option gives robot access to the tenant feed only.
Both host and tenant feeds	Libraries are isolated at the tenant level, meaning data is separated across tenants. You may set an internal or an external feed in which libraries are maintained. By default, an internal feed is used. This option gives robot access to both the host and tenant feeds.
Internal	Displayed when Only tenant feed or Both host and tenant feeds is selected. Use an internal feed for your libraries. The feed can be secured either with the Secure Deployment option or by using an API key: Secure Deployment - Ensures that your automation packages are downloaded through a secure NuGet feed. API Key - The key used to secure your feed against write operations such as delete or upload.
External	Displayed when Only tenant feed or Both host and tenant feeds is selected. Use an external feed for your libraries. The feed can be secured either by using an API key or basic authentication credentials: Deployment URL * - The address where the NuGet feed is located. API Key - The key used to secure your feed against write operations such as delete or upload. Authentication - Enables you to specify the credentials (username and password) for your basic authenticated feed. Please keep in mind that both the username and the password used with the API Key option should be used in this case as well.

For more details, read through the Library feeds page.

Robot Security Tab

Security

Field	Description
Total hours a robot can run offline without license verification	Specify the number of hours a Robot can run offline, without Orchestrator checking its license. By default, it is set to 0. The maximum accepted value is 168 hours.

Robot Authentication

Field	Description
Unattended robot authentication	Client credentials (Recommended) - This option only allows for connections with tokens that expire. It uses the OAuth 2.0 framework as the basis for the authentication protocol, meaning unattended robots can connect to Orchestrator with a client ID - client secret pair generated via machine template objects. The client ID - client secret pair generates a token that authorizes the connection between the robot and Orchestrator and provides the robot with access to Orchestrator resources. Hybrid - This option allows for both connections with tokens that don't expire (machine key) and connections with tokens that expire (client credentials).
Attended robot authentication	Interactive Sign-in SSO (Recommended) - This option only allows for robot connections with tokens that expire. Users can authenticate their robots only by signing-in with their credentials in the Assistant. User sign in is required to run attended robots, make Orchestrator HTTP requests, or view processes in the Assistant. When using interactive sing-in, there is no need to create machine objects in Orchestrator. Hybrid - This option allows for both connections with tokens that don't expire (machine key) and connections with tokens that expire (interactive sign-in or client credentials). Users have the option to sign-in with their credentials to authenticate their robots, which in turn allows them to connect Studio and the Assistant to Orchestrator, however it is not mandatory.

Scalability Tab

Specify if the Robot service should subscribe to Orchestrator's SignalR channels, and configure the transport protocols that work best for you.

SignalR (Robots)

Field	Description
Enabled	This toggle specifies if the Robot service subscribes to Orchestrator's SignalR channels or not. By default, this setting is enabled, and all available channels are selected: WebSocket Server-Sent Events (SSE) Long Polling When all transport channels are enabled, the best available transport is automatically selected, in the following priority order: WebSocket > Server-Sent Events > Long Polling. If the first protocol is not available for any reason, the next in line (if enabled) is used to facilitate the communication between Orchestrator and Robot.
WebSocket	When selected, enables the WebSocket transport protocol to be used to connect the Robot to Orchestrator's SignalR channels. This is the highest protocol used in the order of priority due to its performance and support for simultaneous communication in both directions - from the Robot service to Orchestrator and vice versa. If the SignalR (Robots) feature is not enabled, WebSocket becomes the only available transport protocol.
Server-Sent Events (SSE)	When selected, enables the Server-Sent Events (SSE) push technology to be used to connect the Robot to Orchestrator's SignalR channels. This is the first backup in case WebSockets is not available for any reason. This option cannot be used if the SignalR (Robots) feature is not enabled.
Long Polling	When selected, enables the long polling transport protocol to be used to connect the Robot to Orchestrator's SignalR channels. This protocol is used in case the WebSockets and SSE ones are not available. This option cannot be used if the SignalR (Robots) feature is not enabled.

Non-Working Days Tab

Define a list of non-business days, per tenant, on which you can restrict triggers from running. This means that, during public holidays, weekends, or any other day on which normal business activities are not being carried out, your long-run schedules can be configured such that they don't trigger. Once the defined non-business days are over, the triggers launch as usual.

In order to apply these restrictions to your triggers, you need to select the non-working day calendar when configuring triggers. All changes you make on the Non-Working Days tab affect all triggers that use that calendar.

For more details on how to manage non-working days, click here.

Cloud Connections

This tabs allows you to configure integrations with third-party cloud service providers (CSPs) which are used for elastic robot orchestration.

Cloud Robot Images

This tab lists captured images of customized machines that are used for Cloud Robot - VM.

Managing custom images