- Getting started
- Best practices
- Organization Modeling in Orchestrator
- Managing Large Deployments
- Automation Best Practices
- Optimizing Unattended Infrastructure Using Machine Templates
- Organizing Resources With Tags
- Orchestrator Read-only Replica
- Exporting grids in the background
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read Only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Resource Catalog Service
- Folders Context
- Bulk Uploading Queue Items Using a CSV File
- Managing Queues in Orchestrator
- Managing Queues in Studio
- Review Requests
- Storage Buckets
- Test Suite - Orchestrator
- Test Automation
- Testing Data Retention Policy
- Host administration
- Host Administration Portals
- Configuring System Email Notifications
- Managing System Administrators
- Configuring Host Security
- Host Audit Logs
- Customizing the Login Page
- Maintenance Mode
- Identity Server
- Organization administration
- Managing tags
- Audit Logs
- Overriding System Email Settings
- Other Configurations
Internal packages, namely Orchestrator-hosted feeds packages, are sorted by published date. The published date is the date when the most recent version of a package was published.
Feeds are package streams that allow you to store and group packages in order to control their availability and isolation.
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.
Using v3 NuGet feed URLs results in a couple of display issues with packages.
The publish date of a package is not correct.
For MyGet feeds, the total number of packages is much greater than the actual number of packages uploaded to the feed.
Packages added to the tenant feed are global resources, meaning they are available across folders. They are referred to as simply "packages" and are managed on the Packages page (Tenant context > Packages).
Feed settings and security can be configured from the tenant settings > Deployment tab, either at the tenant level or from the Orchestrator host portal. 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 added to a folder feed are folder-specific resources, meaning they are kept separate and only available in the folder they have been added to. They are often referred to as "folder packages" and are managed on the Folder Packages page (Folder context > Automations tab > Folder Packages).
Only root folders can be configured with a dedicated package feed. All subfolders inherit the package feed setting from the root parent. Access to the feed is controlled by the folder-scoped Folder Packages permission set.
Please note, in Studio, the folder feed might not show up immediately. It is necessary to refresh the Orchestrator connection to display it.
A personal workspace feed resembles a folder feed. Packages published to a personal workspace feed are workspace-specific resources, meaning they are kept separate and only available in the workspace they have been added to. A personal workspace comes with a dedicated feed by default. Packages added to a workspace feed are automatically deployed as processes in the context of that workspace. They are managed on the Folder Packages page (Personal Workspace context > Automations tab > Folder Packages).
Package versioning is configured in Studio when publishing a package to Orchestrator or other custom location. For details on the available versioning schemas, check the Studio article here.
Release notes for a package version and input or output parameters have to be configured in Studio to be accessible in Orchestrator. The first mentioned feature enables developers to track changes between package versions, while the latter enables you to better integrate third-party tools.
A package version can have the following statuses:
- Active - it is currently deployed to a process or a folder;
- Inactive - it is not currently deployed to a process or a folder (only these can be deleted).
To help you migrate packages from one Orchestrator instance to the other with ease, such as from a testing environment to a production one, it is possible to download any version, be it active or not. Please note that this is only possible if you are using an internal feed, and you have View permissions on Packages.
.nupkg archives manually, you can also check if there are any existing processes that can be upgraded and perform that action instantly,
as described here.
.xaml file that is
part of a package version. The file set as Main is labeled accordingly, and all
dependencies are mentioned for each package version. Please note that only packages in
internal feeds can be viewed using the
It is possible to view all the variables, arguments, and imports created for a specific package, exactly like you would in Studio. The properties of an activity are displayed if selected, along with their values, if any. To learn how to view all of these, see Managing Packages.
Please note that flowcharts are displayed similarly to standard workflow diagrams.
.xaml files, presented side by side, earliest file version on the left, with deleted content highlighted in red, modified content
in yellow, and added content in green. Click here to learn how to compare package versions and workflows.
To perform various actions on the Packages page, you need to be granted the corresponding permissions on Packages:
- View - view all package-related details, view which processes can be upgraded, and explore and download packages (these two also require internal feeds);
- Edit - doesn't grant any additional rights at the moment;
- Create - manually upload packages or publish them from Studio;
- Delete - delete inactive packages.
To perform various actions on the Folder Packages page, you need to be granted the corresponding permissions on Folder Packages:
- View - view all folder package-related details, view which processes can be upgraded, and explore and download folder packages (these two also require internal feeds);
- Edit - doesn't grant any additional rights at the moment;
- Create - manually upload folder packages or publish them from Studio;
- Delete - delete inactive folder packages.