- 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
Organization Modeling in Orchestrator
Orchestrator provides multiple features that can be used in modeling your deployment to provide easy and efficient administration while also ensuring proper asset isolation and access control across your organization, regardless of size or structure.
A single Orchestrator instance can be split into multiple Tenants, with each tenant being entirely isolated from any others. No automations, resources, or users are shared or accessible across different tenants.
Each tenant in your organization can be further subdivided and organized into Folders. You can create as many folders as needed to accomplish your desired structure. Each type of folder has various features and capabilities, enabling you to use the appropriate type for managing the administration and sharing of automations across your organization.
Tenants are designed for the purpose of complete isolation of all Orchestrator entities (i.e., Robots, Assets, Queues, etc.) between these segregated instances of your deployment, all without having to maintain multiple Orchestrators. Some examples of separating your Orchestrator into tenants:
- A tenant for each regional or international office of your enterprise, as users from each region have automations specific for the applicable laws and procedures of that region (e.g., HR processes in the USA vs. Europe or Japan).
- Maintaining multiple development and testing environments.
- Isolating sensitive data, such as payroll processes or confidential projects.
Tenants are thus best used in situations where you want all users, resources, and settings of your automation solutions to be managed independently by designated tenant administrators.
Orchestrator folders provide advanced features such as automatic robot management, hierarchical structures, and fine-grained role assignment for users.
Their guiding purpose is to simplify large deployments by enabling the sharing of automations across various departments, integration with your existing AD groups, and expanded control over user permissions and robot creation.
For example, you can create a separate folder for your Finance and HR departments, adding those respective groups from your company Active Directory to their corresponding folder, while also allowing your HR users to have access to the Expense Report automations contained in the Finance folder rather than having to recreate for each separate user or group in your enterprise.