- Getting started
- Best practices
- Organization Modeling in Orchestrator
- Managing Large Deployments
- Automation Best Practices
- Optimizing Unattended Infrastructure Using Machine Templates
- Organizing Resources With Tags
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Setup Samples
- Storing Robot Credentials in CyberArk
- Setting up Attended Robots
- Setting up Unattended Robots
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Audit
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- Organization administration
- Troubleshooting
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 classic or modern 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.
Modern folders provide multiple features not available in the context of classic folders, such as automatic robot management, hierarchical structures, and fine-grained role assignment for users.
The guiding purpose of modern folders 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.
Classic folders function in the same manner as previous Orchestrator versions, preserving full backward compatibility during the transition to the modern model.
Beyond maintaining this backward compatibility for existing deployments, classic folders help provide segregation of automations in less complex deployments where separation by tenant is not needed. In classic folders, user permissions are set at the tenant level with no folder-specific roles available. Users also have access to automations only in those folders to which they are assigned.
Given this added complexity, classic folders are best used for deployments with smaller numbers of robots and administrators.
